Hi!
> class A {
> // This is an *instance* method, but it doesn't actually use $this.
> // This kind of usage is very common in PHP 4 era code, where
> // "static" annotations weren't used
> function test() {
> echo "foo";
> }
> }
>
> class B {
> function test2() {
> // This call would be forbidden because it assumes $this of class
> B, when
> // calling an instance method of class A. However A::test() does
> not actually
> // use $this!
> A::test();
> }
> }
IMHO, this should work. Maybe issue E_STRICT, but even then I'd think
it's not really necessary, I can't see any purpose E_STRICT serves in
this case - since $this is not used, no potential bug is averted, as the
code works exactly as it was supposed to be working.
> This case, where an incompatible $this will be assumed, but never actually
> used, seems to be very common in PEAR, for example. Another weirdness of
> forbidding this call is that the following very similar code would work and
> only throw an E_STRICT notice:
>
> // NOT in a class
> function test3() {
> A::test(); // E_STRICT
> }
Yes, this should work too, and I'm again not sure how useful is E_STRICT
even here.
> The compromise I'd like to implement instead is to only throw a fatal error
> if $this is actually used in the called method and otherwise throw a
> deprecation warning. Calls from instance methods, static methods and
I would go even further and if $this is not there just let it work.
Assuming $this from different context is broken, but if $this not
involved, what's the harm? The call to different context should just
drop $this and treat it as if it were a call from global scope.
> I think this change makes more sense than the original implementation - it
> is symmetric for all static calls and has less BC impact. One case that
> will still be broken is code checking whether $this is set [5] to have
> different behavior for instance and static calls. However this usage is a
> lot more rare and rather questionable in itself.
This should just behave as if $this is undefined there.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
