thanks Deron for initiating the discussion around the rework of our MLContext API (https://issues.apache.org/jira/browse/SYSTEMML-593). Here are a couple of thoughts:
(1) Simplicity: Given that the primary usecase of MLContext calls a script exactly once, I'm wondering if the separation into Script, ScriptFactory, ScriptExecutor and MLContext adds unnecessary complexity by requiring more code to setup. It would be great to see old vs new examples side by side. Also rather than introducing another exception class, couldn't we just reuse DMLException by making it an uncaught exception? (2) Compilation: ScriptExecutor would also be yet another replicate of our compilation chain (beside DMLScript, Debugger, JMLC, MLContext). Please, keep in mind that we are about to consolidate this, centralizing these calls via a configurable compilation chain because it really becomes a maintenance nightmare (as recently seen when we reworked our thread-local configuration management). (3) Data Representation / Converters: Making data conversions and input/output handling easier is certainly useful. However, isn't this new class hierarchy redundant to our already existing hierarchy of Data, MatrixObject, FrameObject, and ScalarObject? (4) Consolidating MLContext and JMLC: This is a good idea since MLContext is anyway "derived" from JMLC and both rely on the same concepts for input/output handling and program modification (see JMLCUtils). Down the road I would like to see a convergence to something like Script and PreparedScript in the spirit of JDBC's Statement and PreparedStatement (btw, that's how we created JMLC). Let's keep in mind that there are already a number of users working against both MLContext and JMLC, so we should support them separately until our major 1.0 release. Regards, Matthias
