|
|
Line 10: |
Line 10: |
| | | |
| The long term plan considers <b>[[RoadmapOAW5|openArchitectureWare 5]]</b>. Version 5 will be integrate what we've learned from using oAW and will come with an additional languages codenamed Xtend++. It will unify Xtend, Check and XPand. | | The long term plan considers <b>[[RoadmapOAW5|openArchitectureWare 5]]</b>. Version 5 will be integrate what we've learned from using oAW and will come with an additional languages codenamed Xtend++. It will unify Xtend, Check and XPand. |
− |
| |
− | == Version 5 ==
| |
− |
| |
− | In Version 5 we want to improve some of the Xtend language concepts and features.
| |
− | Codename is Xtend++ :
| |
− |
| |
− | === Imports ===
| |
− | The 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 import ====
| |
− | A native import refers to another extension file imports all public members (types, functions, extensions).
| |
− |
| |
− | ==== Non-native Import ====
| |
− | A 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 definition ====
| |
− | All members are included without namespace information. If you need a namespace you can explicitely define one per import.
| |
− |
| |
− | ==== Reexport ====
| |
− | The reexport keyword will be supported.
| |
− |
| |
− | === Object construction pattern ===
| |
− | We 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:
| |
− |
| |
− | var e := new Entity {
| |
− | name := "Person";
| |
− | references += new Reference {
| |
− | name := "partner"
| |
− | type := e
| |
− | }
| |
− | }
| |
− |
| |
− | ==== Assignment Expressions ====
| |
− | They are just another syntax for invoking a setter resp. adder-operation (which will be removed).
| |
− | They return the assigned value.
| |
− |
| |
− | === Extensions vs. Functions ===
| |
− | I (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 (<pre>my.ext() vs. ext(my)</pre>).
| |
− | 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.
| |
− | The syntax could look like the following:
| |
− |
| |
− | myFunction(String stuff) :
| |
− | stuff+"-+"stuff;
| |
− |
| |
− | context Entity {
| |
− | javaName() : name.toFirstUpper();
| |
− | allAttributes() : ....;
| |
− | anotherExtension(String name) : ...;
| |
− | }
| |
− |
| |
− | That is functions in a ''context [Type] {}''-Block are extension - everything else is a function.
| |
− |
| |
− | === Code blocks ===
| |
− | I (Sven) would like to discuss a ruby-like code block syntax.
| |
− | A code block is similar to a chain expression ( a-> b-> x) with the additional features:
| |
− | * provides variable declarations (Expression returning void)
| |
− | * support early exit using the 'return' keyword, which forces outer code blocks to exit themselfes.
| |
− |
| |
− | It's something like a pseudo imperative syntax.
| |
− |
| |
− | Example:
| |
− |
| |
− | myExtension(String stuff) : {
| |
− | var x := stuff.length();
| |
− | if (x>56)
| |
− | return "Foo";
| |
− | else {
| |
− | return "Bar";
| |
− | }
| |
− | };
| |
− |
| |
− | A code block is itself an expression consisting of a list of expressions.
| |
− | It returns the value returned by the first executed "return-expression", or the value of the last expression.
| |
− |
| |
− | We should make the colon and semicolon optional so that
| |
− | myExt() { "stuff"; }
| |
− | equals
| |
− | myExt() : { "stuff"; };
| |
− |
| |
− | === if expression ===
| |
− | As seen in the previous example, we want an if-expression. using if, else keywords.
| |
− |
| |
− | if (predicate) expression (else if (predicate) expression)* (else expression)?
| |
− |
| |
− | The else part is optional and will return null if not defined.
| |
− | The following expression will return null:
| |
− | if (false) "Holla"
| |
− |
| |
− | ===Integration of Check===
| |
− | The language check will be integrated into Xtend. That is you can define checks and extensions in the same file:
| |
− |
| |
− | allEntities(emf::EObject obj) : eRootContainer.eAllContents.typeSelect(Entity);
| |
− |
| |
− | context Entity {
| |
− | warning "name "+name+" should start with an uppercase letter" :
| |
− | name.firstToLowerCase()!=name
| |
− | error "duplicate name "+name :
| |
− | allEntities(this).select(e|e.name==name).size==1;
| |
− | }
| |
− |
| |
− | of course you can use everything we have defined before in checks, too. Example :
| |
− |
| |
− |
| |
− | context Entity {
| |
− | error "duplicate name "+name {
| |
− | var entities := eRootContainer.eAllContents.typeSelect(Entity);
| |
− | allEntities(this).select(e|e.name==name).size==1;
| |
− | }
| |
− |
| |
− | === Definition of Types ===
| |
− | So far we couldn't define Types within Xtend but had to define them using other techniques (ecore, Java, UML-profile, etc.).
| |
− | Defining tyoes within Xtend would be a great feature. Because it is much simpler and faster to write them in text.
| |
− | In addition we could define Type with logic (operations).
| |
− | A syntax could look like this:
| |
− |
| |
− | type Entity extends Named {
| |
− | // simple attributes
| |
− | String name;
| |
− | Boolean isAbstract {
| |
− | private set(aValue)
| |
− | get : name.startsWith("Abstract");
| |
− | };
| |
− |
| |
− | // references
| |
− | Set<Entity> superTypes;
| |
− | Set<Features>* features; // asterisk means containment
| |
− | Set<Reference>* references subsets features;
| |
− |
| |
− | // operations
| |
− | doStuff(String x) : x+name;
| |
− | doMoreStuff(String x) {
| |
− | name := x;
| |
− | features += var f := new Feature{
| |
− | f.name:= x;
| |
− | ...
| |
− | };
| |
− | }
| |
− | }
| |
− |
| |
− | === Template syntax ===
| |
− | We want to come up with a simple template syntax integrated into Xtend.
| |
− | Example:
| |
− | context Entity {
| |
− |
| |
− | toJava() :
| |
− | »package «packageName()»;
| |
− |
| |
− | public class «name» {
| |
− | «attributes.each(a|»
| |
− | public «a.type» «a.name»;
| |
− | «)»
| |
− | }«;
| |
− |
| |
− | It's just a string literal with the xpand terminals '«' and '»'.
| |
− | In addition if you use these type of string literals, string concatenation is implicit.
| |
− | Under the hood we might come up with a special string type (for performance reasons), but it should be compatible to the oaw String type and therefore transparent to the user.
| |
− |
| |
− | Files are opened thorugh extensions:
| |
− |
| |
− |
| |
− | generateCode(Entity e) :
| |
− | writeToFile(e.JavaFile(),e.toJava());
| |
− |
| |
− |
| |
− | Something like this...
| |
− |
| |
− | ===Extensions overwrite semantics===
| |
− | Extensions with the same signature will overwrite Operations.
| |
− | Consider overwriting the toString() Operation (which is invoked on String concatenations) for arbitrary meta types.
| |
− | This will allow very readable templates.
| |
− |
| |
− |
| |
− | ===Optional parentheses for operations, functions, extensions without parameters===
| |
− | We should discuss if we want to make empty parentheses on invocations of operations optional.
| |
− | So that :
| |
− | my.operation()
| |
− | equals
| |
− | my.operation
| |
− |
| |
− |
| |
− |
| |
| | | |
| | | |