On 26 October 2014 19:55, Marc Bennewitz <php@mabe.berlin> wrote:
>
> On 12.10.2014 12:10, Nikita Popov wrote:
> > On Sun, Oct 12, 2014 at 10:37 AM, Robert Stoll <p...@tutteli.ch> wrote:
> >
> >> Hey,
> >>
> >>
> >>
> >> I just stumbled over a method call of a non-static method with self and
> >> was asking myself again, why does PHP support
> >> this behaviour. An example to outline what I am writing of:
> >>
> >>
> >>
> >> class A{
> >>
> >> function foo(){
> >>
> >> self::bar();
> >>
> >> }
> >>
> >> function bar(){}
> >>
> >> }
> >>
> >>
> >>
> >> IMO it should not be allowed to call non-static methods with self or
> >> static. Sure, it is just a small detail but for
> >> someone who starts learning PHP it is an unnecessary supplement.
> >>
> >> Maybe it is too drastic to disallow it in PHP 7 but yeah. I would like
> to
> >> know what you think about it and if someone
> >> has a good reason why it is allowed nowadays then please help me out.
> >>
> > There's a common misconception that ::foo() denotes a static method call
> in
> > PHP. What it actually does is a *scoped* call (which is why :: is called
> > the "scope resolution operator" and not the "static access operator").
> >
> > What :: essentially does is give you the ability to call the
> implementation
> > of a method in a particular class. A common application is the use of
> > parent::foo() which will not call your implementation of foo(), but the
> one
> > found in the parent class. Similarly you can use A::foo() to target a
> > particular class that is even further up in the inheritance hierarchy
> > (like, the grandparent-class). You can also call call a class that is
> > completely outside your inheritance hierarchy, but that's deprecated
> since
> > PHP 5.6 and will hopefully be removed in PHP 7.
> Theoretically spoken, the "::" operator would be changeable to "static
> access operator".
> Would that change any behavior outside of calling non static method
> statically?
>
Yes, parent::instanceMethod() forwarding would break, as would forwarding
to methods further up the hierarchy by class name - I wonder if you misread
Nikita's comment above as it uses both of these examples?
Unless you are talking about using a different syntax for these cases maybe?
> Would that open the possibility to register static methods in another
> function table as object methods?
>
Even ignoring the fact that we couldn't really do this anyway (see above),
please no.
We need fewer symbol tables on objects/classes, not more (IMHO). It doesn't
really make sense to have more than one class member with the same name,
unless we are going to support method overloading (which, as has been
discussed many times, we can't ever really do sanely).
The fact that there is more than one symbol table on classes is the reason
we can't do $obj->foo = function() {}; $obj->foo(); - I really don't want
any more wtfs in this regard. If you need the same name for more than one
type of member, then you suck at naming :-P
This is only my opinion, obviously, but it's one I know many share as it is
something that has been discussed at length in the past via various
channels of communication with many people. I'm not actively suggesting we
change the status quo as it has a huge and far-reaching compatibility
impact - we're stuck with what we've got, but please don't make the problem
any worse than it already is.
> So e.g. it would be possible to have "public static __call()" instead of
> "public static __callStatic()".
>
> > Nikita
> Marc
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
