Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
OAW Roadmap
ContentsOverview(Insert text here) Version 5In Version 5 we want to improve some of the Xtend language concepts and features. Codename is Xtend++ : ImportsThe import mechanism should be overworked, so that every import is explicite. We won't need any metamodel configuration in the workflow nor in the editors anymore. This will not only make the setup simpler but will also improve the performance. The syntax would change to something like the following: import org:openarchitectureware:Extension; // native import import EMF "my/package/model.ecore"; // non-native import import UML "my/test.profile.uml" as profile; // non-native import with name space definition Native importA native import refers to another extension file imports all public members (types, functions, extensions). Non-native ImportA non native import starts with an identifier pointing to an installed adapter. The adapter is responsible for loading and converting the members from the given string. The syntax in the string is defined by the adapter. Namespace definitionAll members are included without namespace information. If you need a namespace you can explicitely define one per import. ReexportThe reexport keyword will be supported. Object construction patternWe are thinking about a syntax to create model graphs inline. We need this not only for model transformations but also for writing model transformation tests. Example: new Entity as e { name := "Person"; references += new Reference { name := "partner" type := e } } AssignmentsThey are just another syntax for invoking a setter resp. adder-operation (which will be removed). Extensions vs. FunctionsI (Sven) would like to discuss if it wouldn't be a good idea to explicitely separate between functions and extensions. I think the author of an extension can decide how it should be invoked (my.ext() vs. ext(my)). This would make the syntax more strict, so we can provide better error messages. In addition I think it would make extension files more readable. Here is an example: myExtension(String stuff) : stuff+"-+"stuff; context Entity { javaName() : name.toFirstUpper(); allAttributes() : ....; stuff(String name) : ...; }
|
|