Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:8343
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <4045DE9D.3050107@chiaraquartet.net>
Date: Wed, 03 Mar 2004 08:33:17 -0500
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: Rob Richards <rrichards@ctindustries.net>
CC:  internals@lists.php.net
References: <014501c400be$2190f1f0$f7dea8c0@cyberware.local> <4045553C.3080309@chiaraquartet.net> <018301c4010f$65ffd9e0$f7dea8c0@cyberware.local>
In-Reply-To: <018301c4010f$65ffd9e0$f7dea8c0@cyberware.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: more static method fun
From: greg@chiaraquartet.net (Greg Beaver)

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