headers
president | 1 Dec 2010 01:04
Favicon

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

> ...
>
>> /**
>>  *
>>  */
>> public function set name(string $name) {
>>    $this->name = htmlentities($name);
>>    $this->name = strip_tags($this->name);
>> }
>>
>> /**
>>  *
>>  */
>> public function get name($name) {
>>    return $this->name;
>> }
>>
>> Greetings,
>> Christian
>>
>
> For whatever it's worth, I think that this syntax fits much better
> into PHP than do either of the those in the RFC.

I feel that the downfall of this syntax, is that the get and set methods
can easily be scattered at either end of a class definition.  With the
syntaxes I provided, it is easy to tell which of the methods a property
has defined at a quick glance, because everything is in on spot.

Additionally, public/private/protected/final/abstract/etc only has to be
(Continue reading)

Permalink | Reply | 2 comments |
headers
president | 1 Dec 2010 01:15
Favicon

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

>>      public property Hours read getHours write setHours;
>
> I actually like that, though I think we should support the whole
> existing semantics, i.e. get/set/isset/unset. And probably keep the
> names, so we don't call the same thing both "read" and "get".

This doesn't make sense.  To call isset() on a property, would be to ask
if the property itself exists.  But once defined, a property always exists
(think of methods, for example).

(Sorry for sending again Stas, I forgot to reply all)
- Dennis

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 3 comments |
headers
larry@garfieldtech.com | 1 Dec 2010 01:25
Favicon

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

On 11/30/10 6:15 PM, president <at> basnetworks.net wrote:
>>>       public property Hours read getHours write setHours;
>>
>> I actually like that, though I think we should support the whole
>> existing semantics, i.e. get/set/isset/unset. And probably keep the
>> names, so we don't call the same thing both "read" and "get".
>
> This doesn't make sense.  To call isset() on a property, would be to ask
> if the property itself exists.  But once defined, a property always exists
> (think of methods, for example).
>
> (Sorry for sending again Stas, I forgot to reply all)
> - Dennis

True, but if part of the intent (as noted in a previous email) is to 
provide a mechanism that looks to the outside world like a class member, 
and therefore one can switch between the two without breaking an API, 
then isset/unset should have some sort of useful meaning.  They do for 
__*() magic methods and for ArrayAccess (albeit named differently), so 
there should be some sort of meaningful definition here.  Otherwise they 
are only half a drop-in/break-no-API replacement for a class member.

--Larry Garfield

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
president | 1 Dec 2010 01:29
Favicon

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

>> That is true for PHP variables.  isset is basically saying "does this
>> variable exist", and unset is saying to get rid of it.
>>
>> Because properties (as defined in my RFC) are not a variable, but rather
>> a
>> set of methods, I do not think there would be any way to "unset" them.
>> Like a method, once they are defined, you cannot get rid of them.
>> Therefore "overloading" isset and unset would not make any sense here.
>
> This is different from the PHP Language then. You can isset() and
> unset() "native" properties. And use __isset() and __unset() magic
> methods.
>
> A new feature should be consistent with the language definition.

Its not a matter of consistency - Properties, as a cross-language concept
are not meant to work that way.  You need to think of a property as a set
of two methods that just have a pretty syntax.  Methods cannot be unset,
and nor should properties be allowed to.  isset() should simply tell us
whether a property with the specified name is part of the class or not.

isset() in the way you suggest would just be confusing.  It would allow is
to say that a property does not exist, when in fact it does exist.  This
is not logical.

__isset() is a whole different matter, without it we would have to assume
that every possible member name either exists or does not exist.  This is
because __isset can handle ANY member name.

Properties are bound to a single member name, therefore, they always
(Continue reading)

Permalink | Reply | 1 comment |
headers
Arvids Godjuks | 1 Dec 2010 01:30
Picon

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

You are missing the point in PHP in that case. Because  PHP is dynamic
scripting language, public properties can be added and removed in the
object on the fly. That's why there is isset and unset that works on
object properties. Consider ActiveRecord, DataMappers, ORM, etc. They
use that 100% to their advantage - I haven't yet seen a model witch
defines all the properties in PHP code - mostly it takes table columns
from DB and add these properties in dynamic way.
That's why it isn't so straight forward of adding properties like you propose.

P.S. By the way, maybe I haven't being doing some really crazy stuff
on PHP, but I rarely define getters and setters in my classes that do
something except $this->val = $val and return $this->val. Well,
honestly I haven't worked on some stuff developed by more that 6
programmers too (Latvia is a small county - no major epic projects at
all), but still I think my point is valid.

2010/12/1  <president <at> basnetworks.net>:
>>>      public property Hours read getHours write setHours;
>>
>> I actually like that, though I think we should support the whole
>> existing semantics, i.e. get/set/isset/unset. And probably keep the
>> names, so we don't call the same thing both "read" and "get".
>
> This doesn't make sense.  To call isset() on a property, would be to ask
> if the property itself exists.  But once defined, a property always exists
> (think of methods, for example).
>
> (Sorry for sending again Stas, I forgot to reply all)
> - Dennis
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
president | 1 Dec 2010 01:31
Favicon

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

>> That is true for PHP variables.  isset is basically saying "does this
>> variable exist", and unset is saying to get rid of it.
>
> This is also true for object properties - see magic methods. I don't see
> why you shouldn't be able to unset them - you can do that with regular
> properties... So what you imagine would happen if you call
> unset($foo->property) or isset($foo->property)?

As I replied elsewhere:

Its not a matter of consistency - Properties, as a cross-language concept
are not meant to work that way.  You need to think of a property as a set
of two methods that just have a pretty syntax.  Methods cannot be unset,
and nor should properties be allowed to.  isset() should simply tell us
whether a property with the specified name is part of the class or not.

isset() in the way you suggest would just be confusing.  It would allow is
to say that a property does not exist, when in fact it does exist.  This
is not logical.

__isset is a whole different matter, without it we would have to assume
that every possible member name in a class either exists or does not
exist.  This is because __isset, __get, __set and __unset can handle ANY
member name.

Properties are bound to a single member name, therefore, they always
exist, unless you were to physically remove that property from the class,
which, like methods, that is not possible.

- Dennis
(Continue reading)

Permalink | Reply | 19 comments |
headers
larry@garfieldtech.com | 1 Dec 2010 01:34
Favicon

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

On 11/30/10 5:55 PM, president <at> basnetworks.net wrote:
>> This is a very well-written and well-thought through RFC, Dennis.  Nicely
>> done.
>
> Thank you!
>
>> First of all, I have generally found the Bean-style getter/setter
> approach to
>> be a sign of poor encapsulation to begin with.  You shouldn't be mucking
> with
>> internal elements of an object in the first place, period.  More details on
>> that here:
>>
>> http://www.garfieldtech.com/blog/property-visibility
>
> Interesting post, although I can't say I agree with your views.  Your post
> leaves me wondering how the user is expected to get or give data to a
> class (for example, if I'm not supposed to do $customer->name or
> $customer-getName(), how do I get the customers name?).  Additionally, you
> are forgetting the real power of properties, which is the ability to
> generate a get value, and process a set value, because get/set are
> methods.  Properties are hardly just an indirection layer around an
> underlying piece of data.

The idea of a ->getName() method for retrieving a person's name is fine. 
  My point there is that any assumption that it corresponds to a ->name 
class member (as Bean definitions require) is invalid on its face.  (The 
context there is a lengthy ongoing debate regarding the use of public 
vs. protected class members, with my basic point being that class 
members are an implementation detail and if you care about them in the
(Continue reading)

Permalink | Reply | 0 comments |
headers
president | 1 Dec 2010 01:39
Favicon

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

> Thanks for your reply.
>
> Fundamentally, a big +1 from my little voice on having setters/getters in
> PHP.
>
>
> The issue of documentation is probably that the documentation tools
> would have to adapt. As things stand PHPDoc doesn't support
> namespaces, so setters/getters would just be added to the WIBNI list.

Here is a reply I wrote to Christan Kaps on the same subject:

>  Christan Wrote:
>
>  I like the idea of the property get/set syntax, but in my opinion it
>  doesn't figure with PHP's syntax, because it breaks the readability. The
>  problem for me is the nesting of the inner set and get. How do you
>  document these syntax.
>
>  /**
>   *
>   */
>  public $name {
>
>      /**
>       *
>       */
>      get {
>          return $this->name;
>      }
(Continue reading)

Permalink | Reply | 0 comments |
headers
dukeofgaming | 1 Dec 2010 02:00
Picon
Gravatar

Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations

Hi, first time on the lists, guess I'm from userlando too,

+1 for readability, all I ever really look at are "( ... ){" at the end of
the line so I personally don't think it affects readability. Also, this is
the way its done in other languages and I have always found the function
keyword unnecessary in PHP.

Regards,

David

2010/11/30 Kalle Sommer Nielsen <kalle <at> php.net>

> Hi
>
> 2010/11/30 Patrick ALLAERT <patrickallaert <at> php.net>:
> > With this patch, something looks inconsistent to me:
> > Both properties and methods have a visibility
> > (public|protected|private) and a keyword: "var" (T_VAR) and "function"
> > (T_FUNCTION) respectively.
> > However "private var $foo;" generates a fatal error but "private
> > function foo(){}" not?
>
> The "var" keyword is an alias of the "public" keyword for BC with
> PHP4. So it would be illogically to declare a property both private
> and public at the same time ;-)
>
>
>
> --
(Continue reading)

Permalink | Reply | 0 comments |
headers
larry@garfieldtech.com | 1 Dec 2010 02:09
Favicon

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

On 11/30/10 6:29 PM, president <at> basnetworks.net wrote:
>>> That is true for PHP variables.  isset is basically saying "does this
>>> variable exist", and unset is saying to get rid of it.
>>>
>>> Because properties (as defined in my RFC) are not a variable, but rather
>>> a
>>> set of methods, I do not think there would be any way to "unset" them.
>>> Like a method, once they are defined, you cannot get rid of them.
>>> Therefore "overloading" isset and unset would not make any sense here.
>>
>> This is different from the PHP Language then. You can isset() and
>> unset() "native" properties. And use __isset() and __unset() magic
>> methods.
>>
>> A new feature should be consistent with the language definition.
>
> Its not a matter of consistency - Properties, as a cross-language concept
> are not meant to work that way.  You need to think of a property as a set
> of two methods that just have a pretty syntax.  Methods cannot be unset,
> and nor should properties be allowed to.  isset() should simply tell us
> whether a property with the specified name is part of the class or not.
>
> isset() in the way you suggest would just be confusing.  It would allow is
> to say that a property does not exist, when in fact it does exist.  This
> is not logical.

Consistency with other languages must also be balanced against 
consistency within PHP.  Both are important.

Class members and both existing class-member-ish mechanisms (__magic and
(Continue reading)

Permalink | Reply | 0 comments |

Gmane