the executor's main goals are:
- 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 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