Re: PHP 4.0 Bug #5152: Object passed in a session generates errors when member functions are called
| From: | Stanislav Malyshev | 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