2010/12/1 Eloy Bote Falcon <eloyb...@gmail.com>
> 2010/12/1 Richard Quadling <rquadl...@gmail.com>
>
> On 1 December 2010 09:22, Stas Malyshev <smalys...@sugarcrm.com> wrote:
>> > Hi!
>> >
>> >> 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
>> >
>> > Meant by whom? Is there some law of universe that prevents us from
>> > implementing the feature?
>> >
>> >> 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.
>> >
>> > If you need methods, why not use methods? If you mimick object
>> properties,
>> > however, it makes sense to make them work exactly like property,
>> otherwise
>> > you have to explain why they don't work this way.
>> >
>> >> 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.
>> >
>> > Sorry, from your answer I don't understand - what happens when you call
>> > isset($foo->property) and unset($foo->property)?
>>
>> If we think of properties as this new entity for the language (rather
>> than somehow massaging existing entities to fit a new usage scenario),
>> then
>>
>> isset($instance->property) will always return true for any defined
>> property. Even if the getter would return null. This is new behaviour
>> and can be easily documented. isset() for a property is more like
>> method_exists() than isset() on a variable.
>> With regard to unset($instance->property), from the manual ...
>>
>> "The behavior of unset() inside of a function can vary depending on
>> what type of variable you are attempting to destroy."
>>
>> So, we already have differing behaviour based upon context. Attempting
>> to destroy a property should through a non fatal error.
>>
>> One idea I had was to keep just the get/set property methods and add
>> to them an additional parameter ...
>>
>> <?php
>> public $seconds {
>> public set($value, $unset = False) {
>> if ($unset) {
>> // unset() has been called on the property.
>> // In this instance $value will be Null.
>> } else {
>> // set the property using the supplied $value.
>> }
>> },
>> public get($isset = False) {
>> if ($isset) {
>> // isset() has been called on the property.
>> // If the value is a non-destructive calculation
>> then maybe
>> returning the comparison of the result of the calculation to null.
>> } else {
>> // return the value for this property.
>> }
>> }
>> };
>>
>> So,
>>
>> isset($instance->property) would call $instance->property->get(True);
>> unset($instance->property) would call $instance->property->set(Null,
>> True);
>>
>> This keeps just the 2 property methods. It still allows isset/unset
>> and allows the developer the option of handling them.
>>
>>
>>
>>
>> --
>> Richard Quadling
>> Twitter : EE : Zend
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
> Why change the expected behavior of isset? If a property has not been set
> then isset must return false, and that includes $foo->name = NULL.
>
>
> Regards.
>
Oops, the mail has been marked has spam because of some URI.
Regards.
