On Wed, 2009-03-11 at 22:16 +0100, Olivier Doucet wrote:
> Hello,
> 
> I posted the same topic on the general mailing list, but it appears this can
> be posted here, as it is open to feedbacks and is about PHP implementation
> of static functions.
> 
> I'm wondering if the following behaviour is a bug or a feature. The case is
> quite complex, so let me explain my point of view.
> here is the source :
> 
> <?php
> 
> class MyTest {
>     public function myfunc() {
>         echo get_class($this);
>     }
> }
> class MySecondTest {
>     public function test() {
>         MyTest::myfunc();
>     }
> }
> 
> $test = new MySecondTest();
> $test->test(); //output: "MySecondTest"
> 
> ?>
> 
> In this case, $this is MySecondTest, which is relevant as it is the last
> object context. But to my mind, this code should not work like this.
> 
> Imagine you are the developer of function MyTest. You want your code to
> interact with other classes and being bugproof. 'MyTest' class here seems
> OK: $this is expected to be 'MyTest' because function myfunc() is expected
> to be called in a non-static context.
> 
> Programmer of the second function created this bug and this unattended
> behaviour.
> 
> Maybe this can be done :
> 1/ Forbid calling the function in static context (How can I test this ?
> $this is not NULL there !).
> 2/ (or/and) Raise an error if a non static function is called as a static
> one (if E_STRICT is set, strict warning is already raised).
> 3/ Create two functions with the same name, one static and the other one
> not. Unfortunately, this can't be done (yet ?).
> 
> 
> What do you think ? What's your point of view on this ? I want your
> feedbacks before opening a bug ticket, as it is not strictly a "bug"...

Comments from a lurker...

For better or worse, it's been well documented that what you are
describing is php's behavior and it would be an enormous backwards
compatibility break to change it.  Consider the following example, in
which two generally unrelated class heirarchies have enough in common
somewhere in the tree that some would be inclined to use multiple
inheritance:

<?php
class ABase {
  public $a;
}
class A extends ABase {
  public $x;
  function f() {
    HelpsAandB::f();
  }
}
class BBase {
  public $b;
}
class B extends BBase {
  public $x;
  function f() {
    HelpsAandB::f();
  }
}
class HelpsAandB {
  function f() {
    var_dump($this->x);
  }
}
$example = new A;
$example->x = 5;
$example->f();
?>

Is that a messed up design?  Almost certainly.  Is it a nightmare to
re-design/re-implement many tens of thousands of lines of code that rely
on such behavior?  Unfortunately, that's true also.  (You may have
guessed that I'm responsible for such code and most of it was written
before I joined the company.)

I like to think this rules out options 1 and 2.  I'm not sure about
option 3.

Maybe there could be a function that returns whether the current
function call is associated with the current object (ie whether it was
called via :: or ->).  I'm not an internals expert.

Maybe to address backwards compatibility and address the concern you
raise, there could be a "nonstatic" keyword.  php would throw an error
if a function declared "nonstatic" is called using ::.

- Todd

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to