Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23412
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Mon, 15 May 2006 21:47:06 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <284871631.20060515214706@marcus-boerger.de>
To: Todd Ruth <truth@proposaltech.com>
Cc: internals@lists.php.net
In-Reply-To: <1147721541.14148.47.camel@notebook.local>
References: <138663365.20060514205903@marcus-boerger.de> <038d01c676f8$ab9b3380$6602a8c0@foxbox> <44685D24.2000801@php.net> <1147708994.14148.23.camel@notebook.local> <16710545416.20060515202714@marcus-boerger.de> <1147721541.14148.47.camel@notebook.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] fatal static call in php 6.0?
From: helly@php.net (Marcus Boerger)

Hello Todd,

Monday, May 15, 2006, 9:32:21 PM, you wrote:

> On Mon, 2006-05-15 at 20:27 +0200, Marcus Boerger wrote:
>> Monday, May 15, 2006, 6:03:14 PM, you wrote:
>> > On Mon, 2006-05-15 at 06:51 -0400, Greg Beaver wrote:
>> > ...
>> >> Side note: calling functions statically that do not have a static
>> >> modifier causes E_STRICT.  Hello PEAR::isError()
>> >> 
>> >> This is of course going to be a fatal in PHP 6, but it is now the most
>> >> common E_STRICT I see in PHP4-based code.
>> 
>> > Yikes!  Please say it isn't so!  There are significant portions of
>> > our app that rely on php's ability to make "semi-static" calls.  It
>> > would never be worth the cost of upgrading to php6 if that were the
>> > case.
>> 
>> > It's not the best style, but we have scores of classes that
>> > have several members in common and need common functionality
>> > for those members.  In php5 and earlier, you can add helper
>> > classes and call helper functions with the "::" syntax.  The
>> > helper can access all of the members of the main class as if
>> > it were its own.  The "right" thing to do would be to step
>> > back in the design and move the members to other classes,
>> > etc., but as practical matter, sometimes that's just not
>> > worth the effort to make such drastic changes to code that's
>> > developed by accretion.
>> 
>> > Another use is that we have core data that most classes keep
>> > in an "$application" member variable.  It's sort of like a
>> > global, but to allow for a couple instances of a class to
>> > work on different app data, we've taken the member route
>> > instead of the global route.  php is a nice language for this
>> > in that we don't have to pass $application to every static
>> > function we call.  The static function has access to
>> > $this->application, because everyone who calls the static
>> > function has the application member.
>> 
>> > Please don't fatal error this code in php 6!
>> 
>> > Thanks for listening,
>> > Todd
>> 
>> 
>> Ever heared of the concept named root class?

> Yes, but it isn't a substitute for the semi-statics.  Including
> comments, etc., our php files total about 130,000 lines.  If it
> were a small, simple app, I could shove the helpers into a root
> class and it wouldn't be much worse than the search & replaces
> needed to get to php5.  The arguments against our code would be
> the standard arguments against multiple inheritance.  (The semi-
> statics provide something very similar to multiple inheritance.)
> Like many large apps that have evolved over many years, this isn't
> because it was designed that way; it is because much of it wasn't
> designed at all.  It just grew.  The good news is that it ran
> great on php4 and it hasn't been too much trouble to get rid of
> the issues with getting it to run great on php5.  I'm hoping
> php6 doesn't give up so much backward compatibility that we'll
> never be able to use it.

PHP also offers interfaces.

> BTW, I've tried to come up with a short example to give a flavor
> of what I want to preserve,

No need, i'd just figure misdesign.

> [...]  Is there a significant performance
> enhancement in the engine that depends on eliminating semi-static 
> or somesuch?

Security. We might as well enable the crash function in non debug builds.
Or just drop 'static' again and go back to the PHP 4 object model.

Best regards,
 Marcus