Re: PHP 4.0 Bug #5152: Object passed in a session generateserrors when member functions are called
| From: | Hagenbuch, Chuck | 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