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.
Difference between revisions of "RoadmapOAW5"
(→Imports) |
(→Imports) |
||
Line 17: | Line 17: | ||
import UML "my/test.profile.uml" as profile; // non-native import with name space definition | import UML "my/test.profile.uml" as profile; // non-native import with name space definition | ||
import Java "my.test.Class"; // non-native import introduces java types and features form my.test.Class | import Java "my.test.Class"; // non-native import introduces java types and features form my.test.Class | ||
− | import XSD " | + | import XSD "http://www.mywebsite.org/xsd/metamodel.xsd" // non-native import importing the types from an XSD file |
... (think of Hibernate mapping files, Groovy, etc.) | ... (think of Hibernate mapping files, Groovy, etc.) | ||
Revision as of 10:05, 2 April 2007
Contents
OverviewIn 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 import Java "my.test.Class"; // non-native import introduces java types and features form my.test.Class import XSD "http://www.mywebsite.org/xsd/metamodel.xsd" // non-native import importing the types from an XSD file ... (think of Hibernate mapping files, Groovy, etc.) 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 type information 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: var e := new Entity { name := "Person"; references += new Reference { name := "partner" type := e } } Assignment ExpressionsThey are just another syntax for invoking a setter resp. adder-operation (which will be removed). They return the assigned value. 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. 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 blocksI (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:
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 expressionAs 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 CheckThe 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 TypesSo 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 syntaxWe 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());
Extensions overwrite semanticsExtensions 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 parametersWe should discuss if we want to make empty parentheses on invocations of operations optional. So that : my.operation() equals my.operation
Polymorphic GuardsI (Sven) would like to discuss if we want to have the ability to specify guards on functions, extensions and operations. Example: context Entity { String javaName() {this.isAbstract} : "Abstract"+name; } In addition I would like to use guards in a polymorphic context: context Entity { String javaName() {this.isAbstract} : "Abstract"+name; String javaName() : name; } The dynamic semantics are:
The static semantics are straight forward: The guard must be of type boolean. |
|