Date: 10/27/99
- Next message: ak <email protected>: "[PHPLIB-DEV] error in ct_sql.inc"
- Previous message: Kristian Köhntopp: "[PHPLIB-DEV] Re: [PHPLIB] phplib - changes proposal"
- In reply to: Teodor Cimpoesu: "[PHPLIB-DEV] Re: [PHPLIB] phplib - changes proposal"
- Next in thread: Teodor Cimpoesu: "[PHPLIB-DEV] Re: [PHPLIB] phplib - changes proposal"
- Reply: Teodor Cimpoesu: "[PHPLIB-DEV] Re: [PHPLIB] phplib - changes proposal"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- there is still another global _U(), which can be eliminated at the
cost of a longer serialized representation - ugly, but not a problem.
- 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.
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.
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.
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.
Kristian
-- Kristian Köhntopp, NetUSE Kommunikationstechnologie GmbH Siemenswall, D-24107 Kiel, Germany, +49 431 386 436 00 Using PHP3? See our web development library at http://phplib.netuse.de/ (We have moved! Update your bookmarks!) - 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.
- Next message: ak <email protected>: "[PHPLIB-DEV] error in ct_sql.inc"
- Previous message: Kristian Köhntopp: "[PHPLIB-DEV] Re: [PHPLIB] phplib - changes proposal"
- In reply to: Teodor Cimpoesu: "[PHPLIB-DEV] Re: [PHPLIB] phplib - changes proposal"
- Next in thread: Teodor Cimpoesu: "[PHPLIB-DEV] Re: [PHPLIB] phplib - changes proposal"
- Reply: Teodor Cimpoesu: "[PHPLIB-DEV] Re: [PHPLIB] phplib - changes proposal"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

