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

Edit report at https://bugs.php.net/bug.php?id=75062&edit=1 ID: 75062 User updated by: tomi dot po at koodia dot com Reported by: tomi dot po at koodia dot com Summary: Unload classes / reset php status Status: Suspended Type: Feature/Change Request Package: Scripting Engine problem Operating System: All PHP Version: Next Major Version Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2017-08-11 10:10:21] 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 06:51:12] 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 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