> On 2 December 2010 13:51, <presid...@basnetworks.net> wrote:
>>> 2010/12/1 Richard Quadling <rquadl...@gmail.com>
>>>
>>>> On 1 December 2010 09:22, Stas Malyshev <smalys...@sugarcrm.com>
>>>> wrote:
>> ...
>>
>>> 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.
>>
>>
>> Thats simple then, when isset is invoked, call the get method, and if it
>> returns null then isset() returns false, but otherwise returns true.
>> Â That
>> was likely just a small oversight on Richard's part.
>
> No, it was not an oversight.
>
> Calling the getter() in response to isset() will probably result in a
> change to the value of the property. For a property, isset() can and
> only be interested in the last value of the property, not the next
> value.
>
> As I understand things, isset() performs 2 tests. First a check to see
> if the variable exists and then to see if it has a value assigned.
>
> For a property, the first part of that equation is fairly simple - the
> property has to exist or not.
>
> The second part though is not easy. A variable will not change value
> in response to isset(), but, if isset() calls the getter(), then it
> could and probably would. Calling isset() shouldn't alter anything.
Agreed, isset should not alter anything.
> Having isset() call the getter() and unset() call the setter() is fine
> as long as the getter() and setter() know why they are being called.
>
> If the developer needs to supply the last value - their choice - then
> this could be implemented by caching the last value in a local scope
> static. Completely encapsulated.
>
> get($isset = false){
> static $lastValue;
>
> if (!$isset) {
> // Generate the new value and assign it to $lastValue
> }
>
> return $lastValue;
> }
The major issue I see here, is that a property should not be generating a
value in an unpredictable way. In the example above, you indicate that
the value could change just by calling the get method. While it is
possible to write a property that does such a thing, this is completely
incorrect and should not be actively supported by the language in any way.
The value of a property (as viewed from the outside of the class) should
never, ever change solely by a call to a getter method.
Basically what this means, is that two subsequent calls to a get method of
a property should ALWAYS return the same value. I think this is the only
scenario that we should care to support, and if the user is changing
values in a getter method, then they need to understand that isset may not
work as desired.
If you need to generate and return a random or similar value, that should
be done as a method. See the MSDN article "Choosing Between Properties
and Methods" for more details:
http://msdn.microsoft.com/en-us/library/ms229054.aspx
Isset should be a direct reflection of the value that is/will be returned
by the getter method. If you call isset() on a property, you are asking
"if this property exists, and I access it, will I get a non-null value?".
Not only that, an $isset parameter is ugly and cumbersome, and complicates
a feature that is meant to simplify a programmers life.
Having isset and unset methods alongside the get/set methods seems
reasonable to me, for the situations that you do need to handle those
operations explicitly, but I do not think an isset/unset implementation
should be required in every case (meaning there must be a default way of
handling that functionality), or else properties will be avoided by
programmers due to being to complicated to create.
- Dennis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
