Hi Dave, I think I see what you're saying. Static class variables are associated with the class, if the class persists between requests, so should its static variables.
In the Java model of operation, it's natural to think in these terms, as the Java web server or application server is self-sustained, in the sense that it completely manages its own resources between requests. A static class variable used by a singleton could contain an instance that would be accessible without loading the class and creating the instance again. This is what you mean, right? The typical PHP model is very different (I say typical because you CAN implement a model similar to Java's with PHP too, it is just not how people use PHP); PHP is request/response driven, and except for persistent resources, no run-time-generated data is kept between requests. This is a very fundamental feature of PHP/Zend, and makes PHP very robust, flexible and scalable. If PHP kept run-time data between requests, a lot of the safety net PHP provides (auto-closing resources and auto-freeing memory at the end of requests) would be lost. It would make integration with server backends (such as Apache) more complex, and it would make it harder to scale PHP applications because you introduce state that assumes every request ends up on the same server (or you need a really fast rpc mechanism). I think the approach most PHP developers would take (if they indeed needed this feature) would be to serialize the singleton object and deserialize(clone) it on subsequent requests. Anyway, to ease the pain, have you looked at any of the available PHP code caches, such as APC, ZendAccellerator (commercial) or phpa? http://apc.communityconnect.com/ (or simply run "pear install apc") http://www.zend.com/ http://www.php-accelerator.co.uk/ AFAIK none of these are ported to PHP 5 yet, I know APC and ZendAccelerator will be (never used phpa myself). All of these basically keep the parsed representation of code in shared memory between requests. It doesn't give you persistent class statics, but at least the request startup is much lower. - Stig On Tue, 2004-02-17 at 10:15, Dave Peckham wrote: > Andi (and all), > > You are completely missing my point. I'm not looking > for stateful storage of user variables. If a page > creates an instance of the Person class and assigns it > to $dave, then I expect $dave to go out of scope (and > permanently disappear) at the end of the page request > lifecycle--just like I expect a variable assigned > inside a function to go out of scope when the function > exits. > > What I want the Zend engine to do is recognize that > the Person class need not be loaded and parsed on > every single page. The CLASS (not instances of) should > be managed (i.e. loaded) only once per server. > Therefore, static variables in the class would in fact > be scoped at the classloader level. > > Then, all the pages that use Person class do not have > to parse that class on every page request. This would > be 1) a major performance boost, and 2) enable *real* > use of static members (i.e. for proper implementation > of the Singleton pattern). > > Am I being clear now? > > You know, it's really encouraging to see that the > object syntax in PHP5 is so robust. But if I can't use > the robust syntax to build robust applications, then > what's the point? > > Consider this... there are lots of PHP developers who > get started building relatively simple sites. Over > time, those sites become more complex. At some point, > the requirements of the project (customer) dictate > more advanced technology. If you were to start > including the features I've described, you could > prolong the relevancy of PHP in these solutions. In > other words, what's the growth path of PHP developers > and PHP solutions as needs become more complex? > > Thanks, > Dave > > > --- Andi Gutmans <[EMAIL PROTECTED]> wrote: > > At 10:13 AM 2/16/2004 -0800, Dave Peckham wrote: > > >Hi all, > > > > > >My initial response to Jonathan has me thinking > > more > > >about this, and a higher level. I guess I want to > > hear > > >from the Zend guys about their intentions of PHP as > > an > > >app server. IMHO, that's the right direction. > > > > > >For example, when PHP is loaded by the web server, > > >it's only loaded once, and it should keep track of > > all > > >the classes that get loaded, and only load them > > once > > >(unless the file changes, say). Static variables > > >should apply to the server scope (classloader). The > > >way it stands right now, if all the classes are > > >essential unloaded after each request, then we're > > >still really close to the CGI paradigm. If I have > > >10,000 users who each use 10 pages per session, why > > do > > >I need to load the "Foo" class 100,000 times? > > > > > >Zend guys, what are your thoughts? Was this concept > > >considered and rejected? Your thought process and > > >direction are important to my technology choice. > > > > PHP is pretty much a stateless language. If you want > > to keep a state you're > > going to have to serialize/unserialize to your > > harddisk or DB. There have > > been attempts at creating something similar to an > > app server such as srm > > but they never really took off. In any case, "app > > server" is quite a > > general concept and I could argue that Apache & PHP > > together are an App > > Server. > > > > Anyway, if you really need to persist data/variables > > across requests, there > > are ways to do it (if it's per-Apache process it's > > even easier) but not > > quite as simple as leaving an object floating around > > in main memory between > > requests. > > > > Andi > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Finance: Get your refund fast by filing online. > http://taxes.yahoo.com/filing.html -- "Nearly all men can stand adversity, but if you want to test a man's character, give him power." - Abraham Lincoln -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
