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

<president <at> basnetworks.net>
2010-12-01 00:04:48 GMT

> ...
>
>> /**
>> *
>> */
>> 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

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

<president <at> basnetworks.net>
2010-12-01 00:15:57 GMT

>> 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

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

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

<president <at> basnetworks.net>
2010-12-01 00:29:05 GMT

>> 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

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
>

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

<president <at> basnetworks.net>
2010-12-01 00:31:22 GMT

>> 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

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

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

<president <at> basnetworks.net>
2010-12-01 00:39:42 GMT

> 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;
> }

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

dukeofgaming <dukeofgaming <at> gmail.com>
2010-12-01 01:00:38 GMT

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
>
>
>
> --

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