Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:12617
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <20040906171446.66155.qmail@pb1.pair.com>
To: internals@lists.php.net
References: <4123D1B5.3080203@caedmon.net> <20040819090436.788cd2bf.tony2001@phpclub.net> <5.1.0.14.2.20040819103812.08419700@localhost> <20040820202721.58087.qmail@pb1.pair.com> <20040906122743.54253.qmail@pb1.pair.com>
Date: Mon, 6 Sep 2004 07:58:07 -0700
Lines: 41
Subject: Re: [PHP-DEV] Class Destruction / Reloading
From: pollita@php.net ("Sara Golemon")

> >   I took this in a slightly different direction:
> > http://pecl.php.net/classkit  Any and all thoughts appreciated.
>
> Sara, seems very interesting to me. Anyway, can you please provide me
> your shiva_destroy_class() extension?
>
Shiva's not anything approaching stable or trustable.  It's just a five
minute exercise I wrote for Sean Coates to illustrate some of the inherent
dangers of futzing around with the class table.

If you need class redefinition, I would much sooner recommend
classkit_import() which will aggregate all the methods from a new class
definition over the top of an old class entry. (Note: It's been documented
in CVS, it just hasn't shown in the manual build yet:
http://cvs.php.net/co.php/phpdoc/en/reference/classkit/functions/classkit-import.xml )

I'll also note that while this extensions is more trustable than Shiva, it's
*also* marked as beta.  Sean (who uses this far more than I actually do)
mentioned a bug (non-crashing, but it raises E_ERROR and halts your current
script) when classkit_import() is used under certain conditions (something
involving importing multiple classes in a single file, we're working through
the specifics still).

If you don't so-much want to redefine the class as undefine it, I suppose it
could be done safely by following the idea in Zeev's earlier post which
involves "hiding" the class rather than outright destroying it.  That way if
there are any instances hiding in some obscure symbol table somewhere (e.g.
another instantiated object, a static variable hash or a local variable hash
in an upstream function/method) they'll still have a class_entry to refer
to.  This is something I could add to classkit, but because the class
definitions don't really disappear but are rather just "hidden", it'll
appear to "leak" a little bit of memory each time it's used so again, I'd
recommend classkit_import() over it.

Before you ask: No, it's not "simple enough" to just go looking through
those symbol tables to see if any instances exists.  Possible yes, practical
no.

-Sara