Re: PHP 4.0 Bug #5152: Object passed in a session generates errors when member functions are called
| From: | thies at digicol dot de | Date: | Wed, 21 Jun 2000 18:24:11 +0000 |
| Subject: | Re: PHP 4.0 Bug #5152: Object passed in a session generates errors when member functions are called | ||
| References: | 1 2 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-21923@lists.php.net to get a copy of this message | ||
On Wed, Jun 21, 2000 at 08:12:16PM +0200, Sascha Schumann wrote:
> On Wed, 21 Jun 2000 thies@digicol.de wrote:
>
> > On Wed, Jun 21, 2000 at 07:14:56PM +0200, Sascha Schumann wrote:
> > > > Bottom line: please don't do this. This is bad hacky behaviour. In fact,
> > > > even stdClass is bad hacky behavour... I'd promote that warning to error
> > > > and thus forced right usage of session objects, but that could be too
> > > > bondage-and-discipline...
> > >
> > > We are currently discussing an easier method which simply
> > > caches the class name between unserialization and
> > > serialization, so that no extra dummy class needs to be
> > > created.
> >
> > i'm for the class-on-demand creation. i don't think that this
> > will cause any problems. is you include your classs code
> > after session_start() you'll get a "cannot redeclare
> > class-name" this way. (this would also be this 1st step into
> > creating a class-on-demad loading mechanism)
> >
> > if we go with sascha's way (remembering the class-name
> > somewhere) you will be able to create a new class but your
> > sessionized object wouldn't be able to call the methods.
>
> You also won't be able to call them, if you create a dummy
> class with the same name.
but you will retain the class name from page-to-page (our
primary goal) without haveing to include the classes code in
every page.
>
> The on-demand loader would need to reside inside of our
> current serialization framework. What I basically propose is
> to leave a gap for an on-demand loader while the fallback
> procedure would preserve the class name. I don't see a reason
> why we need dummy classes in this scenario.
because people will include their classes code *after* they
loaded the session-data. and that will be confusing.
with what you suggested something like
<?
session_start();
include "some_class_code_here";
?>
won't even issue a warning even if the classes needed for
deserialisation of the session data are 1st defined in the
"some_class_code_here" file.
just wait for the commit ...
tc
>
> - Sascha
--
Thies C. Arntzen "One Big-Mac, Small Fries and a Coke!"
Digital Collections Phone +49 40 235350 Fax +49 40 23535180
Hammerbrookstr. 93 20097 Hamburg / Germany