|
|
| (97 intermediate revisions by 11 users not shown) |
| Line 1: |
Line 1: |
| − | {| border=0
| + | #REDIRECT [[OAW]] |
| − | | width=90% |
| + | |
| − | == Overview ==
| + | |
| − | | + | |
| − | 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
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | | valign=top |
| + | |
| − | {| border=0 cellspacing=3 cellpadding=4
| + | |
| − | ! bgcolor="Gainsboro" | OAW Navigation
| + | |
| − | |-
| + | |
| − | | bgcolor="GhostWhite" | [[OAW| Main Page]]
| + | |
| − | |}
| + | |
| − | |}
| + | |
