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

From: Date: Wed, 21 Jun 2000 17:05:46 +0000
Subject: Re: PHP 4.0 Bug #5152: Object passed in a session generates errors when member functions are called
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-21917@lists.php.net to get a copy of this message
S>> 1) For every single damn page you go to, you MUST have included S>> the header file, or session_start() will complain. This is true even S>> for pages that DON'T USE THAT CLASS AT ALL. So if you reg a IF YOU DO NOT USE THAT CLASS, you shoudn't include it in session. Session is not for carrying everything and the kitchen sink, it's for session variables - i.e., for variables that constitute a session, i.e. used by every script participating in the session. If your variable is rarely used, you should use other storage method. Otherwise, you are abusing session mechanism and you are getting punished for it. S>> 2) You can't just require() it ahead of time. I've tried require() and S>> include() and neither one works. It just complains about std_class. So you tried it wrong. S>> If I put require()/include() AFTER session_start() then they are S>> auto-loaded but without methods. Why would you put them *after*? What exactly prevents you from putting them *before*? If you insist of misusing PHP on general principle, don't complain about it not working. PEBKAC. S>> When the deserialize method is called, IMHO, it should NOT S>> even ATTEMPT to autoload a class. You should call S>> $myvar = session_load_class("my_class") to pull it out. This method S>> does not currently exist, but I'm looking at adding it. Well, if you want to add "class loaders", whatever it be - you are free to show your code. But if you know you class enough to load it, why won't you just define it and let PHP to do the work? Also, remember that at the end of request sessions is saved. If you didn't load some variables, they'd be eliminated from the session, so you just lose them. In fact, adding handler that will be called on unknown class load could be a solution, but I fear it'll create more problem than solve, because it looks like a kludgy hack. S>> That route fixes the std_class problem, the "no methods" problem, There's no std_class problem. You are misunderstanding how PHP sessions are working. S>> and you won't have to include the header files (if you have 40 classes S>> it could be a problem) on pages that don't even USE the classes. Not If you don't use them, don't put them in sessions. S>> only is it smoother, but you're not autoloading everything that you're S>> not using and therefore don't take the performance hit for it. Exactly. Don't load what you don't use. I think PHP code *can* be patched to auto-define new classes, but that makes more problem than solves - you still couldn't call methods, and your class definition is plain wrong, i.e. you just call it "class foo", but you've got no object of this class, just a fake. That's No Good (TM), even if it could solve some immediate problem. Also, you won't be able to redefine this class later. -- Stanislav Malyshev stas@zend.com +972-3-6139665

« previous php.dev (#21917) next »