On 1 December 2010 10:23, Eloy Bote Falcon <eloyb...@gmail.com> wrote:
> 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
>> @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
>>
>> --
>> 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.
>

Say the property is write-only. How can isset() operate on that? If
the property is read-only, how can you unset() it?

If properties are abstractions to methods, then they don't serve a purpose.

If properties are wrappers for locally cached values then they
isset/unset is feasible.

If properties are to "... provide the illusion of having normal class
variables ..." ... then it is undefined if there is a real value held
anywhere.

You do not want isset() to have to get() the value of the property as
the getter may be getting the data from (for example) a DB, SOAP
request, etc. Getting the data is not as simple as just returning a
local value.

I think isset() and unset() for properties is different to that for
variables. Either isset() and unset() generate errors when called on
properties, or, with an amendment to the syntax, isset() and unset()
are passed to the setter and getter (if they exist) to allow the
developer of the property to decide what to return.



-- 
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to