Re: RFC: C-sharp style property get/set syntax for PHP

On 12/2/10 8:42 AM, president@basnetworks.net wrote:

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.

I don't believe PHP has function references per se. It has the ability to call functions dynamically by either: $function = 'foo'; $function(); // or call_user_func[_array]('foo'); (The former is faster so preferred if you have a fixed number of variables.) Functions are not first-class entities in PHP the way they are in, say, Javascript so you can't pass them around, nor do you have "function pointers" as you do in C. (My god those are a nightmare to code...) PHP 5.3 introduced anonymous functions/closures, which seem at first blush to be sort of like that. However, I believe the internal implementation is done using objects and you can mimic that behavior on an object using an interface, so really functions still don't have a first-class status but are emulated using objects. (I'm sure one of the compiler people can correct me if that's not entirely accurate.) </tangent>

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?

I'm not sure. I'm just pointing out that "behaves like class members" is a substantially more complex scenario than it seems at first blush, and we need to think through the implications of that and just how closely we can emulate properties.

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

I agree that is a good guideline to follow. It also provides a natural answer to the isset/unset question: If you try to isset/unset a class member that doen't exist but __get() does, what happens? (That may not always be the right answer, but it's a comparison we should make.) From another reply:

The basic Idea of a property, is making a getFoo() / setFoo($value) pair of methods look and act like a variable from the outside, and have an easily identifiable and simple to use syntax on the inside. The reason I originally focused so much around methods, is because properties literally

are a pair of methods in C# (thats what they are compiled into). But PHP is another beast, and the challenges are different. As long as the original purpose of properties is not loss, whatever way we figure out is best to implement them is fine with me.

The "original purpose" being, specifically, "smarter class members", correct? (The internal syntax to define them we can bikeshed later; determining the external syntax and semantics has to come first.) --Larry Garfield