Class Destruction / Reloading

php.internals

Sean Coates

22 years ago
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Internals, Has anyone given thought to a feature that allows (PHP) developer to invalidate classes (allowing the developer to re-load the class, with modified code)? I realize that this is not possible now, and for good reason. But I think the idea has potential. I asked Sara about this, yesterday, after the idea occurred to me, and she graciously whipped up a small extension that does exactly what I'm looking for, but she told me she thought it was a bad idea to be doing this (and also allows destruction of functions). I agree: without the proper safety nets, this is a dangerous thing to be doing. So, why do I want this functionality, in the first place? Consider a long-running application (not a web page, but, for instance, a sockets-based application). It would be very useful for me, as a developer, to be able to re-load parts of the application, without tossing the whole current instance of PHP (and all associated resources) - -- ie, doesn't release socket connections, but allows re-loading of the associated handlers. This could be accomplished by invalidating a class (destroying it, and marking all instanciated objects with a special type (__PHP_Destroyed_Class comes to mind, after __PHP_Incomplete_Class), and re-declaring the class. - -- sample code (working) -- <?php eval('Class Foo { function name() { echo "Foo\n"; } }'); Foo::name(); shiva_destroy_class('Foo'); eval('Class Foo { function name() { echo "Bar\n"; } }'); Foo::name(); ?> - -- output -- Foo Bar I also spoke (typed) with Stig, who told me that this sounds more like a PHP 6 feature. I understand that class destruction breaks a lot of assumptions. As Sara pointed out, it will definitely break optimizers. Also, the potential for segfault is very high: Class Foo { function name() { echo "Foo\n"; } }; $Foo = new Foo(); shiva_destroy_class('Foo'); eval('Class Foo { function name() { echo "Bar\n"; } };'); $Foo->name(); results in segfault.. I'm, admittedly, completely out of my league here.. I played with the API a little, and was reminded of this. (-: It may seem like a stupid idea at first, but I think there's some value in re-loading pieces of code, and with the proper object counting/invalidation, sounds like it could be safe, but like I said, I don't know what I'm doing. Is this worth further discussion? S -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBI9G1WppknrQMxQIRAjPOAJ9gsQ6AZlwd5QI6+CYerGOgtsKwhQCfejxZ zfMP6MgKuGvHx7dO4mPNh90= =GR/W -----END PGP SIGNATURE-----

Greg Beaver

22 years ago
Sean Coates wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello Internals, > > Has anyone given thought to a feature that allows (PHP) developer to > invalidate classes (allowing the developer to re-load the class, with > modified code)? I realize that this is not possible now, and for good > reason. But I think the idea has potential.
[snip]
> Is this worth further discussion?
There is a clever php4 implementation that allows loading/unloading of methods, info at http://pear.php.net/pepr/pepr-proposal-show.php?id=68 It does not use any engine magic and might be of use to you while you wait for PHP 6. :) Greg

Marcus Börger

22 years ago
Hello Sean, Thursday, August 19, 2004, 12:01:25 AM, you wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1
> Hello Internals,
> Has anyone given thought to a feature that allows (PHP) developer to > invalidate classes (allowing the developer to re-load the class, with > modified code)? I realize that this is not possible now, and for good > reason. But I think the idea has potential.
[................]
> Is this worth further discussion?
Not before until we have an application server and php scripts that are designed to run for several months. And even then we would also need improved Reflection support and conatiner support and so on and so on. Best regards, Marcus mailto:helly@php.net

Sean Coates

22 years ago
Marcus Boerger wrote:
>>Is this worth further discussion? > > Not before until we have an application server and php scripts that are > designed to run for several months. And even then we would also need > improved Reflection support and conatiner support and so on and so on.
No disrespect intended, but this sounds like a chicken-and-egg problem to me. S (PS- Wez, I remembered to turn off my signing this time (-: )

Andi Gutmans

22 years ago
At 08:23 PM 8/18/2004 -0400, Sean Coates wrote:
>Marcus Boerger wrote: > >>Is this worth further discussion? > > > > Not before until we have an application server and php scripts that are > > designed to run for several months. And even then we would also need > > improved Reflection support and conatiner support and so on and so on. > >No disrespect intended, but this sounds like a chicken-and-egg problem >to me.
How's that? I think what Marcus is telling you that with the way PHP works and the way it is used request-response paradigm, it really doesn't make sense. Andi

Michael Walter

22 years ago
Andi Gutmans wrote:
> At 08:23 PM 8/18/2004 -0400, Sean Coates wrote: > >> Marcus Boerger wrote: >> >>Is this worth further discussion? >> > >> > Not before until we have an application server and php scripts that are >> > designed to run for several months. And even then we would also need >> > improved Reflection support and conatiner support and so on and so on. >> >> No disrespect intended, but this sounds like a chicken-and-egg problem >> to me. > > > How's that? I think what Marcus is telling you that with the way PHP > works and the way it is used request-response paradigm, it really > doesn't make sense.
I think Sean is talking about creating an application server _in PHP_. Cheers, Michael

Andi Gutmans

22 years ago
At 03:30 AM 8/19/2004 +0200, Michael Walter wrote:
>Andi Gutmans wrote: >>At 08:23 PM 8/18/2004 -0400, Sean Coates wrote: >> >>>Marcus Boerger wrote: >>> >>Is this worth further discussion? >>> > >>> > Not before until we have an application server and php scripts that are >>> > designed to run for several months. And even then we would also need >>> > improved Reflection support and conatiner support and so on and so on. >>> >>>No disrespect intended, but this sounds like a chicken-and-egg problem >>>to me. >> >>How's that? I think what Marcus is telling you that with the way PHP >>works and the way it is used request-response paradigm, it really doesn't >>make sense. >I think Sean is talking about creating an application server _in PHP_.
I understood that. Andi

Sean Coates

22 years ago
>> I think Sean is talking about creating an application server _in PHP_. > I understood that.
My chicken and egg comment was this logic: Marcus: the reason we don't need this is because we don't have [an application server] that would require it. Sean: the reason we need it is because I'd like to develop [an application server] Where [...] could be anything. I understand the common use of PHP. Do we expect PHP to grow into a general purpose language? (if not, then I think I misunderstand the CLI SAPI). S

Rasmus Lerdorf

22 years ago
On Wed, 18 Aug 2004, Sean Coates wrote:
>>> I think Sean is talking about creating an application server _in PHP_. >> I understood that. > > My chicken and egg comment was this logic: > > Marcus: the reason we don't need this is because we don't have [an > application server] that would require it. > Sean: the reason we need it is because I'd like to develop [an application > server] > > Where [...] could be anything. > > I understand the common use of PHP. Do we expect PHP to grow into a general > purpose language? (if not, then I think I misunderstand the CLI SAPI).
The fact that various features and add-ons exist that make PHP useful outside of the web space does not in any way imply that focus is shifting away from web applications as the primary use of PHP. Things that can be done that don't intefere with that primary use and model and are generally useful to people will be done. Things that in any way hamper that primary use face a stiff uphill battle when it comes to being accepted. All this talk of PHP becoming Java or other such nonsense is getting annoying. PHP is getting stronger in order to provide more powerful tools to solve the same set of problems people have been using PHP for all along. -Rasmus

Robert Janeczek

22 years ago
>> Is this worth further discussion? > > Not before until we have an application server and php scripts that > are designed to run for several months. And even then we would also > need improved Reflection support and conatiner support and so on and > so on.
don`t you think that lacking this destruction/loading causes potential app server developers to drop their idea? i`m working on such thing and working on components in write code-[ctrl-c server]-load server isn`t fun at all :] rash

Marcus Börger

22 years ago
Hello Robert, Thursday, August 19, 2004, 10:29:31 AM, you wrote:
>>> Is this worth further discussion? >> >> Not before until we have an application server and php scripts that >> are designed to run for several months. And even then we would also >> need improved Reflection support and conatiner support and so on and >> so on.
> don`t you think that lacking this destruction/loading causes potential app > server developers to drop their idea? i`m working on such thing and working > on components in write code-[ctrl-c server]-load server isn`t fun at all :]
Could you share some more infos about that project? marcus

Robert Janeczek

22 years ago
> Could you share some more infos about that project?
sure the project itself is my university thesis, its topic might clear some things: 'Hive -distributed server for message-driven componental PHP applications'. main idea is to be able to create php applications in RAD-way. for this to be possible i designed componental architecture based on messaging system. it is exacly the way php is NOT designed to be used ;) all this with transparent component distribution in mind. server runs as standalone appliacation. http daemon uses sockets to transfer request parameters and fetch results - later i`ll probably build into app server simple httpd. server is ('will be' mostly) coded in php, so changes can be made easily, but if my idea will be useful i have in mind rewriting code in c. no stress tests have been made so far - to much coding is still to be done. it is mix of ideas from java, windows messaging and few very theoretical books. behind my back lies 1 meter high mountain of books :) from practical point of view - its something like srm, at least i think so - i`ve never used it. from the beginning its designed for php5 new super duper mechanisms. by now you probably realized why i`ve showed up in this thread - ability to manage components flexible is crucial in my project. i need for example way to detect class name collisions before compiler dies with error - there is no way to control naming conventions for components. i thought about some nasty ideas like forcing names in HIVE_UUID form, but as you surely understand - its horrible solution. probably i`ll have to use second process to load component and use reflection to check for collisions before loading in main app server process. rash ps. no thread support sucks :]

Antony Dovgal

22 years ago
On Wed, 18 Aug 2004 18:01:25 -0400 Sean Coates <sean@caedmon.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello Internals, > > Has anyone given thought to a feature that allows (PHP) developer to > invalidate classes (allowing the developer to re-load the class, with > modified code)? I realize that this is not possible now, and for good > reason. But I think the idea has potential. >
<skip>
> - -- sample code (working) -- > <?php > eval('Class Foo { function name() { echo "Foo\n"; } }'); > Foo::name(); > shiva_destroy_class('Foo'); > eval('Class Foo { function name() { echo "Bar\n"; } }'); > Foo::name(); > ?> > - -- output -- > Foo > Bar
Well, some time ago I wrote a small functions, that does exactly the same: PHP_FUNCTION(unregister_class) { zval **class; zend_class_entry *ce = NULL, **pce; char *lowercase_name = NULL; if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &class)==FAILURE) { ZEND_WRONG_PARAM_COUNT(); } convert_to_string_ex(class); if (zend_lookup_class(Z_STRVAL_PP(class), Z_STRLEN_PP(class), &pce TSRMLS_CC) == SUCCESS) { ce = *pce; } if (!ce) { RETURN_FALSE; } lowercase_name = emalloc(ce->name_length+1); zend_str_tolower_copy(lowercase_name, ce->name, ce->name_length); if (zend_hash_del(CG(class_table), lowercase_name, ce->name_length+1) == FAILURE) { efree(lowercase_name); RETURN_FALSE; } efree(lowercase_name); RETURN_TRUE; } Dunno if it's a good implementation, but the idea was to be able to reload classes in the looong running PHP application. However, I don't think it should be implemented in PHP ever, 'cos this (and many more) functionality is/should be implemented in SRM.
-- Wbr, Antony Dovgal aka tony2001 tony2001@phpclub.net || antony@dovgal.com

Sara Golemon

22 years ago
> Well, some time ago I wrote a small functions, that does exactly the same: > > PHP_FUNCTION(unregister_class) > {
*snip* Barring some stylectic differences and a check to make sure it's not an internal class, that's precisely what I gave sean in shiva_destroy_class().... But just to be clear, I don't think it's a good idea, and I'll wager dollars to doughnuts that it destablizes the active request if not the entire engine. Not to be too blunt, but I gave him that extension so he'd have some rope to hang himself with (or maybe learn something useful...) -Sara

Zeev Suraski

22 years ago
At 08:32 19/08/2004, Sara Golemon wrote:
> > Well, some time ago I wrote a small functions, that does exactly the same: > > > > PHP_FUNCTION(unregister_class) > > { >*snip* > >Barring some stylectic differences and a check to make sure it's not an >internal class, that's precisely what I gave sean in >shiva_destroy_class().... > >But just to be clear, I don't think it's a good idea, and I'll wager dollars >to doughnuts that it destablizes the active request if not the entire >engine.
From the technical perspective, it's actually easy to implement in a rock-solid manner. Don't kill the class completely but just clean any functions/properties inside of it, and mark it as dead. Then patch the class declaration begin code to check for this flag, and reuse the class structure instead of complaining about reregistering a class. There might be some more cleanup necessary in PHP 5, but if any, it shouldn't be too complicated. But I agree with you that it's a bad idea :) Zeev

Sara Golemon

22 years ago
> From the technical perspective, it's actually easy to implement in a > rock-solid manner. Don't kill the class completely but just clean any > functions/properties inside of it, and mark it as dead. Then patch the > class declaration begin code to check for this flag, and reuse the class > structure instead of complaining about reregistering a class. There might > be some more cleanup necessary in PHP 5, but if any, it shouldn't be too > complicated. >
I took this in a slightly different direction: http://pecl.php.net/classkit Any and all thoughts appreciated. Function Entries: bool classkit_method_add(string classname, string methodname, string args, string code[, long flags]) bool classkit_method_redefine(string classname, string methodname, string args, string code[, long flags]) Note: flags parameter requires PHP >= 5.0.0 bool classkit_method_remove(string classname, string methodname) bool classkit_method_rename(string classname, string methodname, string newname) Constants (passed in flags parameter): CLASSKIT_ACC_PUBLIC CLASSKIT_ACC_PROTECTED CLASSKIT_ACC_PRIVATE -Sara

Alex Pagnoni

21 years ago
Sara Golemon wrote:
> 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? I need something similar in order to reload classes for an open source EJB like system I built, when redeploying code with already declared classes. Rasmus was right when he said "PHP is getting stronger in order to provide more powerful tools to solve the same set of problems people have been using PHP for all along", when talking about the "PHP becoming Java". I love PHP and I use it wherever possible, coding in PHP is fun for me; and more features may means more new possibilities, such as that project I built. I know that it is using PHP in a way it wasn't originally meant for; but it works, and PHP made it possible, and if it allowed me to do it, then it is "legal" to do such sort of things ;) PS. For the interested ones, this is a list of current features: - Encapsulates business logic in a Carthag Business Module (CBM) - Delivers optional persistance, with Value Objects and Data Access Objects - CBM deployer - Transparent access to remote CBMs as if they were local - Transparent access to local CBMs without using CBM server - Location of CBMs through a CBM locator descriptor - Own socket server for receiving requests and serving classes - Uses XML-RPC as communication protocol - Uses PHP internal XML-RPC server implementation for faster speed - Watchdog for monitoring CBM server and restarting it in case of failure - Supports CBM session for the entire lifetime of a remote object Alex

Alex Pagnoni

21 years ago
Please excuse me for repeated messages, I got some timeouts when posting from the news server gateway.

Sara Golemon

21 years ago
> > 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

Alex Pagnoni

21 years ago
Sara Golemon wrote:
> 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 Sara, thank you very much for your suggestion. This should be enough for my needs, I'm going to study/test it. Redefining only is ok for me, anyway having the option of removing (hiding) a class may be interesting too. Alex

Alex Pagnoni

21 years ago
Sara Golemon wrote:
> 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? I need something similar in order to reload classes for an open source EJB like system I built, when redeploying code with already declared classes. Rasmus was right when he said "PHP is getting stronger in order to provide more powerful tools to solve the same set of problems people have been using PHP for all along", when talking about the "PHP becoming Java". I love PHP and I use it wherever possible, coding in PHP is fun for me; and more features may means more new possibilities, such as that project I built. I know that it is using PHP in a way it wasn't originally meant for; but it works, and PHP made it possible, and if it allowed me to do it, then it is "legal" to do such sort of things ;) PS. For the interested ones, this is a list of current features: - Encapsulates business logic in a Carthag Business Module (CBM) - Delivers optional persistance, with Value Objects and Data Access Objects - CBM deployer - Transparent access to remote CBMs as if they were local - Transparent access to local CBMs without using CBM server - Location of CBMs through a CBM locator descriptor - Own socket server for receiving requests and serving classes - Uses XML-RPC as communication protocol - Uses PHP internal XML-RPC server implementation for faster speed - Watchdog for monitoring CBM server and restarting it in case of failure - Supports CBM session for the entire lifetime of a remote object Alex

Alex Pagnoni

21 years ago
Sara Golemon wrote:
> 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? I need something similar in order to reload classes for an open source EJB like system I built, when redeploying code with already declared classes. Rasmus was right when he said "PHP is getting stronger in order to provide more powerful tools to solve the same set of problems people have been using PHP for all along", when talking about the "PHP becoming Java". I love PHP and I use it wherever possible, coding in PHP is fun for me; and more features may means more new possibilities, such as that project I built. I know that it is using PHP in a way it wasn't originally meant for; but it works, and PHP made it possible, and if it allowed me to do it, then it is "legal" to do such sort of things ;) PS. For the interested ones, this is a list of current features: - Encapsulates business logic in a Carthag Business Module (CBM) - Delivers optional persistance, with Value Objects and Data Access Objects - CBM deployer - Transparent access to remote CBMs as if they were local - Transparent access to local CBMs without using CBM server - Location of CBMs through a CBM locator descriptor - Own socket server for receiving requests and serving classes - Uses XML-RPC as communication protocol - Uses PHP internal XML-RPC server implementation for faster speed - Watchdog for monitoring CBM server and restarting it in case of failure - Supports CBM session for the entire lifetime of a remote object Alex