You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
saving state, e.g. preserving variables, defined functions/classes, etc. from previous inputs.
handling errors, e.g. handle fatal errors in input code without terminating the console process
there are 2 main alternatives to execute (input) code in php
internal: include, eval, etc.
external process: exec, etc.
with internal commands saving state is much easier as variables could be stored (without the need of passing from one process to another), functions and classes will be defined in the global scope (available in the console process). using an external process on the other hand requires some kind of serialization to pass data from the external process back to the console process (so that it can pass it to the next external process). this poses a few difficulties, like serializing (and unserializing) user defined and framework objects (like models and collections, possibly controllers, etc.) or closures (PHP has some limiting functionality to 'inspect' closures, but it boils down to parsing back the closure from the file), not to mention functions/files.
error handling is the other way around, it is almost trivial with external processes and somewhat impossible with internal commands (there are errors which cannot be 'catched'/caught and will terminate the console process).
it seems that we can't have both and given the complexity of serializing/unserializing i think giving up the error handling is the better choice, but i created this ticket to elaborate on the issue
The text was updated successfully, but these errors were encountered:
Actually, passing state and things like closures to an external process is quite easy, and involves no serialization of any kind. In fact, it can be done in the same way it's handled for saving state now: by having the main process write to a PHP file, and telling the executor what file to include.
I extracted the core functionality (with a working external executor, see ExternalExecutor). However there's still a little 'gimmick': i use a special string (written to STDOUT by the external process, read by the main one, see line 47 and line 169) to know if the execution ended successfully. I tried to get around it with other techniques but i couldn't come up with a satisfying solution. Do you have any idea, or do you think relying on this is adequate?
the executor's main goals are:
there are 2 main alternatives to execute (input) code in php
with internal commands saving state is much easier as variables could be stored (without the need of passing from one process to another), functions and classes will be defined in the global scope (available in the console process). using an external process on the other hand requires some kind of serialization to pass data from the external process back to the console process (so that it can pass it to the next external process). this poses a few difficulties, like serializing (and unserializing) user defined and framework objects (like models and collections, possibly controllers, etc.) or closures (PHP has some limiting functionality to 'inspect' closures, but it boils down to parsing back the closure from the file), not to mention functions/files.
error handling is the other way around, it is almost trivial with external processes and somewhat impossible with internal commands (there are errors which cannot be 'catched'/caught and will terminate the console process).
it seems that we can't have both and given the complexity of serializing/unserializing i think giving up the error handling is the better choice, but i created this ticket to elaborate on the issue
The text was updated successfully, but these errors were encountered: