Re: PHP 4.0 Bug #5152: Object passed in a session generateserrors when member functions are called

From: Date: Thu, 22 Jun 2000 11:58:33 +0000
Subject: Re: PHP 4.0 Bug #5152: Object passed in a session generateserrors when member functions are called
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-21959@lists.php.net to get a copy of this message
Quoting Stanislav Malyshev <stas@zend.com>: > HC>> You honestly don't think it would be reasonable to have a global user > HC>> state/authentication object that _all_ pages used, and then to have > HC>> sub-sites of > > It would be. It would be also good to have it's class defined - or how > would you want to use it anyway??? ... you trimmed off the part of my email that was more relevant! Of course you would include the class definition everywhere. It's the other objects that you wouldn't want to have to define in every single page. Let me make this more concrete. Say you're writing a suite of web applications. You've got a core authentication and user state class, which is included in every page on your site. Now, the suite includes a calendar, an email program, a contact manager, a forum... etc. For each of those applications, you have user preferences that you want to cache in the session so you don't look them up on every page load, and you can toss in some data caching - of the things they have to do today, for example - as well. As things now, you have several choices: 1. Use classes to define those cache structures, and on every single page in your site, include the class definitions for every class that might be in the session. Problem: you're including a lot of useless code on a lot of pages. 2. Use classes to define the cache structures, and every time you add something to the session (the first time the user hits a new app), set a cookie or something that tells you that class is being used. Before you call session_start(), include the class definitions for everything that is in the session. Problem: you're still including useless code on a lot of pages, just less of it a bit less of the time. 3. Don't use classes for anything stored in the session. Use hashes, etc. Problem: I know php isn't a full-blown OO language, and that's fine. But it does seem like there are people who want to make use of the OO features, and that means using objects in sessions. Personally, I've chosen #3 because it's the simplest right now. No kludges, no worries about where classes are defined. But is it really so unreasonable to want to toss an object into the session, and only use it - ie, include its class definition - if the user comes back to that page, or the same set of pages? -chuck -- I won't die for Fernando Poo

« previous php.dev (#21959) next »