Re: RFC: C-sharp style property get/set syntax for PHP
| From: | president at basnetworks dot net | Date: | Wed, 01 Dec 2010 13:10:55 +0000 |
| Subject: | Re: RFC: C-sharp style property get/set syntax for PHP | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-50775@lists.php.net to get a copy of this message | ||
>>>> 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)?
>>
>> Its not a matter of consistency - Properties, as a cross-language
>> concept
>> are not meant to work that way.
> I tend to disagree.
> The need to be consistent inside of PHP has precedence over being
> consistent with other languages.
Unfortunately I find that to be one of the major downfalls of PHP. It
sometimes disregards defacto standards that are set across the entire
industry, which causes a lot of frustration for new programmers.
Sometimes the functionality PHP adds by going its own way is worth it, but
often it is just a confusing mess. Thats just my opinion though, YMMV.
>> 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..
> I think, it really is the other way around.
> Properties are meant to give the programmer the illusion that she is just
> having a field.
> That is abstraction. She does not care about implementation details.
> And that is the power of properties.
>
> isset() and unset() are perfectly fine in that context.
> And I do not see a problem to provide the standard semantics for them
> automatically, and let the programmer add isset/unset methods to the
> property as needed in exactly the same style as get/set.
>
> There is a good usecase for asking whether a property has been set, for
> instance to verify initialization.
> And, of course unset has also a useful meaning. It is about the value, and
> even so there are methods around a value, properties are meant to be
> values.
> There are definitely use-cases where that does not hold, but that is
> application specific.
>
>
>> 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.
> From the docu: isset Determine if a variable is set and is not NULL
> There is nothing confusing about isset($this->Hours) == FALSE in your
> example if isset($this->seconds) == FALSE.
Right, I understand how it would work, and the reasons why it would "make
sense", but it just feels wrong to me. When you unset() a variable in a
class, that whole variable is gone. Its not just hiding somewhere, its
completely gone. If a property were to "pretend" it is not set, with an
isset method, it would still be there - just hiding. That is why it does
not make sense to me.
- Dennis