Req #75062 [Opn]: Unload classes / reset php status

From: Date: Fri, 11 Aug 2017 06:51:16 +0000
Subject: Req #75062 [Opn]: Unload classes / reset php status
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-210594@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=75062&edit=1

 ID:                 75062
 Updated by:         requinix@php.net
 Reported by:        tomi dot po at koodia dot com
 Summary:            Unload classes / reset php status
 Status:             Open
 Type:               Feature/Change Request
-Package:            Dynamic loading
+Package:            Scripting Engine problem
 Operating System:   All
 PHP Version:        Next Major Version
 Block user comment: N
 Private report:     N

 New Comment:

This certainly is a very specific use case, and a temporary one at that. Shouldn't you be
determining which system handles the request as soon as possible - before B begins executing?

Having and old and new framework is your situation but that isn't itself a problem. So what is
the actual problem that resetting symbol tables is supposed to solve?


Previous Comments:
------------------------------------------------------------------------
[2017-08-11 06:40:31] tomi dot po at koodia dot com

Description:
------------
I am proposing a functions "unload_all_classes()", "unload_included_files()" or
"reset_php()"

Basically the idea is to reset the PHP back to the status when the program started, yet continue
from the next line of code after the function call.

Scenario: legacy system A, new system B, both systems need to run concurrently, it depends on
condition C, which system need to be executed to handle the request. This condition C, is something
that can be determined only inside the code. 

In this scenario I thought that maybe if I start the request and execute system B, but if it
determines that this request is not intended for that, it'll simply fold - reset back to its
status, and run legacy system A to handle the request. The point is to ease the migration pains.

Further developement could return a "savepoint", so that you could get back to the
original state. Something like this:

"Savepoint function reset_php( Savepoint $savepoint = null )"

"If savepoint is null, resets back to the original state (in which the php started) and returns
the old state (savepoint).

If savepoint is not null, and is legitimate savepoint it will reset the php status to this
savepoint, and returns the old savepoint - otherwise returns FALSE.

In either case the execution continues from the next line.
"






------------------------------------------------------------------------



--
Edit this bug report at https://bugs.php.net/bug.php?id=75062&edit=1


Thread (4 messages)

« previous php.bugs (#210594) next »