Community
Participate
Working Groups
Considerations: * Update Bound AST Tree to use IR objects instead of Binding objects * Update the Compiler to use IR objects instead of Binding objects * Refactor all validation rules to work on IR objects instead of Binding objects * Refactor the existing validation framework so that the current validation rules are contributed as extensions * Refactor and execute the existing validation JUnit test framework * Update approach for defining stereotypes * Update approach for managing annotations in the AST tree * Extensible generator template path * Extensible system IR path Future * Update all IDE utilities to work on IR objects instead of Binding objects Notes: * We will leave the Working Copy Compiler alone for as long as necessary, so that all IDE utilities can continue to create Binding objects as necessary * We will start a new compiler, which is invoked in a 'command line' only mode, to experiment with a new parser and a bound AST tree using IR objects. We will not touch the existing compiler * The first attempt for I1 will be to create a bound AST tree using IR objects for a simple program * Next we will start to define the extensible validation framework and begin to port our existing validation rules to this framework * If the validation framework is completed in time for .8, we will replace the Compiler used in the Builder and the Dynamic Red Squiggles (Editor) with the new Compiler [NOTE: We may choose to extend .8 by some amount of time to finish this work as necessary]
Some random thoughts: 1) currently we have different compile levels of bindings. Bindings that are still being compiled or are returned from a level 1 compile are marked as "not valid". Bindings that are completed following a level 2/3 compile, or that are deserialized from an IR on disk are marked as valid. We will need a similar way to represent this information in the binding level IRs. For now, I will code this so that an annotation is added to an IR when it is considered to be valid. 2) Should the api names be changed from getBinding()....to something else (such as getIRBinding() or getBindingLevelIR()?). For now I will simply change the return type from PartBinding to Part and see how it goes. If it becomes too muddled, I may need to change the API name. 3) The processing for the system parts will need to change. Currently all the IRs in the archives are read and converted to Bindings and then stored in the SystemEnvironment. Since we are no longer doing this conversion, this is probably a good time to change the processing to not read in the IRs when the system environment is initialized. It should just read the entries to find what parts are saved in the archive. The IRs can be deserialized as they are requested and then cached in the system environment. 4) Need a way to clear the Binding level IRs so that the same object can be used for different levels of compilation. This will probably just entail a utility to reinitialize the slots in the IR.
I've split some of this work into separate bugs: 386739 enh P3 --- Compiler extension framework Compiler 0.8.2 jspadea@us.ibm.com 386740 enh P3 --- Update IBMi, SQL, and services core implementation to use new framework Compiler 0.8.2 jspadea@us.ibm.com 386742 enh P3 --- Update validation to use the new IR binding model Compiler 0.8.2 jspadea@us.ibm.com 386747 enh P3 --- Type validation should run off the MOF model Compiler 0.8.2 jspadea@us.ibm.com 386748 enh P3 --- Port existing JUnit test cases Compiler 0.8.2 jspadea@us.ibm.com 386749 enh P3 --- Update IDE for extensible compiler changes IDE Core 0.8.2 jspadea@us.ibm.com
Done
