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. BTW, I've tried to come up with a short example to give a flavor of what I want to preserve, but anything short is too easy to refactor and say "it should have been done differently". It's true that many aspects of our app should have been done differently, but its difficult to change something so large. I don't see benefits of making semi-static fatal that make it worth keeping those of us with large apps that depend on semi- static from upgrading to php6. Is there a significant performance enhancement in the engine that depends on eliminating semi-static or somesuch? - Todd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
