Hi Larry,
>> Hmm, I would have programmed it liked this:
>>
>> if ($account->beneficiary != null) {
>> print $account->beneficiary->name;
>> }
>>
>> To me, if a property is "not set", it means it does not exist and will
>> not
>> be a valid property at any point in the object's lifetime. Null means
>> that it is a valid *possible* property, but does not currently hold any
>> value. This thinking is consistent with other languages. (I move
>> between
>> languages on a daily basis, so consistency is key to keeping my sanity!)
>
> One certainly could implement it that way, but that would throw an E_NOTICE
> if you're using class members and $account->beneficiary is not set. So
that
> makes properties an incomplete drop-in for class members.
Hmm, I will have to contemplate that some more.
>> > Thinking about properties further, actually, there's two other (related)
>> > considerations that always give me grief when dealing with __get:
>> > Reference returns and complex member variables.
>> >
>> > If I want a reference to a class member, I can very easily do this:
>> >
>> > $foo = &$bar->baz;
>> >
>> > If ->baz is accessed via __get(), then that only works if __get() is
>> > defined as function &__get($var) to start with. That's another
>> > encapsulation break.
>>
>> If baz is a property, I would imagine:
>>
>> $foo = &$bar->baz;
>>
>> would get a reference to the property itself, not a reference to the
>> return value of the set method. Therefore each call to the new
>> reference
>> would call either the get or set method, and would not operate on the
>> return value of the get. Just a note, C# does not support references to
>> properties, and yes, they break compatibility with variables by doing
>> that.
>
> How does one get a reference to a property, if a property is just a
collection
> of methods with fancy behavior? That makes properties a first class
entity,
> which is an entirely different bit of brain bending.
Its the same concept as having a reference to a function, where you can
invoke the reference and it invokes the function. I say that as a
programming concept, not a PHP concept, because I am a bit fuzzy in the
"function reference" department of PHP.
> (Making properties a free-form super-variable that are not bound to a
class is
> a cool concept, but not at all what we're discussing here AFAIK.)
Right, that is not what this RFC is looking to achieve.
>> I imagine to get a reference to the return value of a property, you
>> would
>> do something like this:
>>
>> $foo = &($bar->baz);
>>
>> > Similarly, the following does exactly what you'd expect with a normal
>> > class member:
>> >
>> > $foo->bar['baz']->narf = 'poink';
>> >
>> > If $foo->bar is returned via __get(), though, then the above statement
>> > executes but does not actually save anything... *unless* __get() was
>> > defined to return by reference as above.
>>
>> Ok I think I understand what you are saying. In this case, $foo->bar is
>> returning an array. You then access ['baz']->narf from that array.
>> Arrays are always passed by reference, are they not? If so, than the
>> above would work fine, no? Because $foo->bar would just be returning a
>> reference to some array, which you then modify.
>
> Actually that's subtly wrong, which is the point I'm making. :-) If
> $foo->bar
> is a class member, then $foo->bar['baz'] dereferences from $foo to bar,
> does
> an array key lookup, finds an object, dereferences to the narf class
> member,
> and assigns "poink" to that. No new variables are ever created.
>
> If $foo->bar is accessed via __get(), then $foo->bar *returns* an array by
> value; the ['bar'] index of that new array is then accessed, we find an
> object
> there,that gets dereferenced to narf, and we assign 'poink' to that, in the
> new array.
So is the solution then to make the set method return by reference? Or
does that just create more problems?
> My question regarding properties here would be: There are subtle and
> irritating differences between class members as __get() that make the
latter
> not a true replacement for the former, especially when dealing with
arrays as
> I've not found a way to work around those yet. What subtle and irritating
> differences between class members and properties would we introduce, and
would
> they be the same subtle and irritating inconsistencies or an entirely
new set
> of subtle and irritating inconsistencies to have to deal with?
I would say, try our best to resolve all of the inconsistencies, and if we
cannot, then make sure they are the same inconsistencies that __get and
__set have, to be as least confusing as possible.
- Dennis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
