Ken Stanley wrote:
As for parent/self:: and even static::, what makes
them static is the scope resolution operator (::), not their name.
Their name just implies the context in which they are to be used.
That's right. And that's exactly why it's such a bad idea to call it
static::. It's the scope resolution operator which already makes them
static, not their name. (I'm sorry for catching you on your words ;) )
Perhaps we should forget about the whole keyword and just allow objects
to access its static members like any other member? It works like that
for static functions too. Why not let it act that way for static
variables?:
I would have to disagree with you on this subject. The whole point of
having
a static model is the ability to access members of classes without
having to
instantiate them.
That's not right. Accessing the child class would only be possible from
within an instantiated object. Unlike parent::, you will never be able
to use static:: in a purely static context. Imagine there are multiple
child classes which all inherit from the same base class. If there's no
instance, PHP won't be able to know which child class to target with
child::, static:: or whateverkeyword:: since it can be any one of those
child classes.
ClassName::classMember is completely different than
$className->classMember. Using the former means that you do not necessarily
have an instantiated object of ClassName, but in the latter it is implied
that you do. I would think that using $this::classMember in the wrong place
could lead to some very troubling errors at run-time.
Since there's no use for it in a static context anyway, I think
static::, child:: or whateverkeyword:: would be confusing for
developers. Since this would only work from withing an instance, I
thought it might be a better idea to make static members accessible
through $this->. (I think I even expected this to work when I first
found out it didn't ;) )
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
