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

At 08:05 PM 6/21/00 +0300, Stanislav Malyshev wrote: >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. I'm using certain objects, sparsely, as a frontside cache to reduce the number of pure database hits. webserver+mySQL webserver+mySQL \ / \ / \ / One Centralized Database >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. I've tried them both ways. I tried them with ham. I tried them with eggs. I've tried the every damn way you can think of. > >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? Because PHP doesn't seem to work. I looked at the loading code, contrary to what you may think, from CVS. > >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. > Why not just NOT auto-load classes, and if you want access to a class, you NEW it and then say session_load_object("type", &var) or something? Or have the session_load_object("type") just allocate for you? Someone said a couple posts back that I'm "very verbal." Yes. Yes I am. You don't effect change by sitting on your ass. You don't go anywhere in life by just saying "oh, well, I guess I'll just cope." I will apologize for being so wordy, and annoying. That is not my intent at all. Someone also said that I wasn't using the whole ideology of a session correctly. Okay, I'm off to go read it yet again. I'm a systems programmer for NT. NT is not applicable here, but the concepts don't change and I'm quite sure that the last couple of times I've read the session stuff I didn't miss anything but I'll take another pass at it. I'd like to see the object-session model change. If no one else will do it, I will. I just got confirmation from my side job (the one using PHP) that they'll pay for my time to massage it since they'll get use of it as well. I'm going to reread everything, and make sure I'm not wasting my time, their money, or anything else. Maybe I'm coming across wrong; I know I did initially. In the beginning I came on with the attitude that you guys (basically Zend) owned PHP. Rasmus set me straight and I'd like to help...if you can put up with me. I'm not attacking anyone, or saying I can do any better. I'm simply saying that I'm willing to take a stab at it and see if I can make a difference to make life easier. I know from side emails that I'm not the only one playing with this stuff and having difficulties; I'm simply the most verbal. I also have a long way to go in tracing all of the macros and learing the model PHP was build on, and the underlying concepts. Can I drop my frontside cache, and not use registered classes? Ayup. Will I? For now, yes. But I think that registered sessions is just too damn cool and holds way too much promise for future projects/fun. Once things change (I do it, someone else does it, I suddenly realize in a flash of light that I'm approaching this thing all wrong) then I'll recode some stuff on the site to use the class goodies. -Szii