[PHPLIB-DEV] Re: [PHPLIB] phplib - changes proposal From: Teodor Cimpoesu (teo <email protected>)
Date: 10/27/99

Kristian Köhntopp wrote:
>
> Teodor Cimpoesu wrote:
> > Okay, but I would apreciate to say what's wrong. You mean using other
> > globals variables or just the way I wrote the serialize() ?
> There are more problems to your approach. I have taken your diff and applied
> it to my example code. As far as I can see
okay, thank you for taking you time , let's see ...
 
> - there is still another global _U(), which can be eliminated at the
> cost of a longer serialized representation - ugly, but not a problem.
k, I also though of making it a Session method (so $this->_U(.))

> - you do serialize all slots of an object, which is an error. While it
> is a good default to serialize all slots of an object and PHPLIBs
> serialize function should be changed to work that way, there are
> certain cases where is it neither correct nor desireable to serialize
> all slots.
oh, I see! That was one thing I ignored cause I didn't undestood why
exatcly
would one need persistent slots. On the other hand, if I want all the
properties
of an object to be persistent that would generate a long code of
$this->property=val assignments instead of a simple string.

> For example, in many cases a class contains constants or pseudo constants
> such as Host, User, Password and Database in DB_Sql. These do not normally
> change and need not be serialized. You can serialize them without harm, but
> that would make your serialized data unnecessarily large.
yes, this really makes sense
 
> For example, sometimes variables in an object are not the real data, but
> refer to external objects which cannot be serialized properly, because you
> have to way to deal with them directly from within PHP.
>
> Such objects are for example database links or images. All you get for
> these objects is an object handle. It is an error to serialize such
> a handle, because on the new page you would deserialize that handle,
> but it is invalid and the object that handle refers to is no longer
> present. In such cases the current code relies on the fact that the
> handle has not been serialized and is now zero. The code will then
> recreate the external object, e.g. by reconnecting to the database.
okay
 
> In the current code we serialize only the slots of an object that are
> enumerated in the persistent_variables slot. We rely on that functionality
> and any replacement code must duplicate it to be useable.
okay, you're right, I'll play with the slots :)

thank you again for enlightment

regards, 

-- 
CIMPOESU Teodor, Web Programmer

@ DIGICOM S.A. Bucharest, Romania
@ Internet, site development
@ teo <email protected>,+(401)-330.47.28

official home page ~ http://www.digiro.net/
Internet  web page ~ http://internet.digiro.net/
-
PHPLIB Developers Mailing List. Send messages to <phplib-dev <email protected>>.
To unsubscribe, send "unsubscribe" to <phplib-dev-request <email protected>> in
the body, not the subject, of your message.