Hi Rob,

Rob Richards wrote:

From: Greg Beaver



The PEAR base class also has this design flaw in several methods. It
has caused nothing but annoying and unfixable bugs. The only good
solution is to redesign by splitting the methods into two methods, one
static, one not. It's best to do this before the stable label is
applied, unless you like getting the same valid bugs reported over and
over with different permutations :)



Say dom load were split into 2 methods (this is not something that should be required to do). One static and one a regular public function. As shown with the simplexml example, the regular function would still not work correctly. The method I used in that example, is not a static method, but if called within another class method, it is allowed to be called using the static syntax

To quote Microsoft, "this is a feature, not a bug." :) Of course, if someone tries to call a non-static method from another completely unrelated class, that's just stupid. But there are cases where you might want to call a method from a parent class 2 levels up.

class one {
   function doSomething() {}
}

class two {
   function doSomething() {}
}

class three {
   function doSomething()
   {
      $a = one::doSomething();
   }
}

Here, it's perfectly logical to allow :: as it is in fact not a static method call. If PHP removes this feature, it will break a lot of code I've written that has been working in a production environment for the past 2 years without a single glitch.

I've also written code to emulate runtime multiple inheritance that relies upon using a method from another class that expects certain properties to be available in the class, and this works great.

There is a certain amount of control that PHP can enforce, but in this case, I think it's up to the programmer's intelligence to understand how class hierarchies work, and not write code that fails. One point you raised that is significant to me is the crash, I don't think it's all that good that PHP 5 crashes instead of failing with some kind of fatal error.

Greg

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



Reply via email to