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