On 12/2/10 8:42 AM, presid...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
