php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #75062 Unload classes / reset php status
Submitted: 2017-08-11 06:40 UTC Modified: 2017-08-11 12:28 UTC
From: tomi dot po at koodia dot com Assigned:
Status: Suspended Package: Scripting Engine problem
PHP Version: Next Major Version OS: All
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: tomi dot po at koodia dot com
New email:
PHP Version: OS:

 

 [2017-08-11 06:40 UTC] 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.
"

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-08-11 06:51 UTC] requinix@php.net
-Package: Dynamic loading +Package: Scripting Engine problem
 [2017-08-11 06:51 UTC] requinix@php.net 
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?
 [2017-08-11 10:10 UTC] cmb@php.net
-Status: Open +Status: Suspended
 [2017-08-11 10:10 UTC] cmb@php.net 
Thank you for your interest in PHP and for submitting a feature
request. Please be aware that due to the magnitude of change this
request requires, it would be necessary to discuss it on PHP
Internals list (internals@lists.php.net) as an RFC. Please read
the guide about creating RFCs here:
<https://wiki.php.net/rfc/howto>. If you haven't had experience
with writing RFCs before, it is advised to seek guidance on the
Internals list (<http://php.net/mailing-lists.php>) and/or solicit
help from one of the experienced developers. 

Please do not consider this comment as a negative view on the
merits of your proposal – every proposal which requires changes of
certain magnitude, even the very successful and widely supported
ones, must be done through the RFC process. This helps make the
process predictable, transparent and accessible to all developers.
 [2017-08-11 12:28 UTC] tomi dot po at koodia dot com 
That would be nice if it was possible to determine to which system to direct this call.

For example, suppose we have : 
/info?location=somelocation

and /info?location=A is supposed to be handled by new system, but then location=B should be handled by legacy system, but only until a specific datetime and/or contents of the database. There is a lot of different kind of usecases, and tens of locations  and not all locations are moving into a new system at a same time. In most cases I would agree, but in this case I felt that it might actually be simplest course of action to simply fold, and reset the request and have older code to figure out the rest. This would also allow the implementation of the new and legacy systems in a simple manner; one url at a time. None of this would be a problem if the systems wouldn't have a number of classes that have the same name, but different implementation (thus the unload thought). 

Rare and temporary use case, I agree.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 20:01:29 2024 UTC