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.
Cheers,
Robert
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.
The use of self::, static:: (or parent:: for that matter) itself doesn’t make a method call static; it’s the declaration or caller context that makes it behave statically, i.e. $this can’t be used.
In your given example, $this is defined when A::bar() is called; interestingly, when this class is extended it will still only call A::bar() as opposed to calling $this->bar(). Whether this is useful behaviour is irrelevant :)
The use of static::bar() is kind of pointless, because AFAICT there’s no difference between that and $this->bar() in this particular example.
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.Cheers,
Robert
In your given example, $this is defined when A::bar() is called; interestingly, when this class is extended it will
still only call
A::bar() as opposed to calling $this->bar(). Whether this is useful behaviour is irrelevant :)
Right, I completely forgot that. So calling it with self instead of $this actually could make sense.
Cheers :)
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.
Nikita
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?
Would that open the possibility to register static methods in another
function table as object methods?
So e.g. it would be possible to have "public static __call()" instead of
"public static __callStatic()".
Nikita
Marc
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
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.
Yes please, remove that non-sense.
And that will simplify some parts of code into the engine as well :-)
Julien.P