Re: PHP 4.0 Bug #5152: Object passed in a session generateserrors when member functions are called
| From: | Andrei Zmievski | Date: | Thu, 22 Jun 2000 16:59:01 +0000 |
| Subject: | Re: PHP 4.0 Bug #5152: Object passed in a session generateserrors when member functions are called | ||
| References: | 1 2 3 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-21971@lists.php.net to get a copy of this message | ||
On Thu, 22 Jun 2000, Matthew Kendall wrote:
> I've been following this discussion with interest and I had an idea I wanted
> to share.
>
> In the above situation, if the areas are developed seperately there is more
> than just the problem of class definitions. What if both developers decice
> to use a variable called $foo, and serialise it? We have a name conflict.
>
> Here is my idea. Divide sessions into seperate namespaces. There is one
> namespace called Global. If you don't specify a particular namespace when
> you add a variable to a session it gets put in the Global namespace. You
> would use this for variables needed on all pages of a site, and you would
> expect to define all associated classes on each page. All variables in the
> Global namespace are automatically de-serailised at the start of a session.
> This gives complete backwards compatibility.
>
> But you could also define arbitrary namespaces within the session. Say
> Calendar and Todo. The person writing the Calendar part of the site
> specifies the Calendar namespace when she puts variables into the session.
> The person writing the Todo list part of the site specifies the Todo
> namespace. These namespaces are not automatically de-serialised at the start
> of the session. You have to explicitly ask for them with a new function, say
> retrieveSession('Calendar'). You are expected to include all associated
> class definitions before doing this, but you only have to define the classes
> for the variables you put in your namespace. You can be entirely unaware of
> all the other namespaces.
>
> You might say, about the $foo example above, that the developers should have
> just agreed to have used $calendarFoo and $todoFoo, but this is just
> implementing namespaces in a kludgy, manual way. Better to do it properly.
>
> I haven't looked into the details of this and I am not an expert on
> sessions, but I wanted to share this idea because it seems so nice. I'm sure
> it could be made backwards compatible, and it seems to me to solve peoples
> problems.
I actually like this idea. Something to think about though is whether to
use one function session_namespace() that would set the namespace for
saving/retrieving sessions or to use a manual session namespace
retrieval like you mentioned. Another problem might be what to do if
both Global and Calendar namespaces have the same variable - what
overrides what.
-Andrei
Programming X-Windows is like trying to find
the square root of pi using roman numerals.
- Unknown