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"
Line 1: | Line 1: | ||
{| border=0 | {| border=0 | ||
| width=90% | | | width=90% | | ||
− | + | = Collection of features (rough) = | |
+ | |||
+ | == Xtend == | ||
In Version 5 we want to improve some of the Xtend language concepts and features. | In Version 5 we want to improve some of the Xtend language concepts and features. | ||
Line 439: | Line 441: | ||
I don't understand what you mean by, checks have to be modified. | I don't understand what you mean by, checks have to be modified. | ||
+ | == XPand == | ||
=== PF added --- to be discussed === | === PF added --- to be discussed === | ||
==== Add a FOLDER keyword ==== | ==== Add a FOLDER keyword ==== |
Revision as of 05:14, 21 November 2007
Contents
Collection of features (rough)XtendIn Version 5 we want to improve some of the Xtend language concepts and features. Codename is Xtend++ : ImportsThe import mechanism should be reworked, so that every import is explicit. 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. The token directly after the import keyword defines which adapter to use. 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, so that imported stuff (types and functions) will be reexported. Example: myext1.ext foo() : 'foo'; myext2.ext import myext1 reexport; bar() : 'bar'; client.ext import myext2; fooBar() : foo()+bar();
GenericsWe need full-fledged generics, which can conceptually be copied from Java's generics. Maybe we can leave out some of the more advanced capabilities? ClosuresWe'll have real closures, not the built-in stuff we have now. Closure syntax: parameterList '|' expression-using-parameters-and-scope Where parameter list must be typed, either implicitly or explicitly. Example: // type of e is inferred from the declaration of the 'select()' function myList.select(e|e.name == "test") or { String myText := "test"; (Attribute)=>Boolean myClosure := e|e.name==myText; // e is inferred from the declared type of the assignee myList.select(myClosure); } alternatively declare the parameter types explicitly { var myText := "test"; var myClosure := Attribute e|e.name==myText; myList.select(myClosure); }
Type signatures of functionsThe syntax for of a function's type signature looks as follows: (parameterTypes)=>returnType Examples: ()=>Object (String)=>Boolean (String, Entity)=>Entity Example 2: declaration of higher-order functions using generics : List<T> select<T>(List<T> this, (T)=>Boolean closure) { ... } FunctionsFunctions can be invoked either using the functional syntax or using the member syntax (operation like, aka extensions): myFunction(foo, bar) == foo.myFuntion(bar) A function is declared as follows: (private|cached) ReturnType? functionName(declaredParameterList) guardExpression? : bodyExpression ; Example: private doStuff(Entity this) name!=null : name+"Stuff"; The detailed semantics of how the polymorphic resolution works (what role guards play here) and is described in the upcoming section. or (private|cached) functionName(declaredParameterList) guardExpression blockExpression Example: cached makeAbstract(Entity this) { abstract := true; name := 'Abstract'+name; return this; } Block expressions are explained in their own section. Polymorphic Resolution with signatures and guardsUsually polymorphism is based on the types of parameters. The same applies for Xtend++. In contrast to e.g. Java we use the dynamic types (actual types at runtime) of a given set of parameters in order to find the function which best fits (has the most specific declared paramter types). Example: given the following two functions foo(String x) : "string"; foo(Object o) : "object"; this assertions can be made: foo('S') == "string" foo(34) == "object" foo((Object)'S') == "string" // would be "object" in Java In addition to these concept, commonly known as "multiple dispatch" or "multi method", we introduce guards which can be used to controll the resolution based on the state of a given object not only the type. Example: foo(String x) x.length>5 : "long"; foo(String x) : "short"; this assertions can be made: foo('honolulu') == 'long' foo("bar") == 'short' The semantics are as follows:
pseudo code for (Feature f : features) { if (f.hasGuard()) { if (f.guard.evaluate()) return f; // return the feature where the guard evaluates to true } else { return f; // return the feature without a guard } } return null; // no invocation
The static semantics are straight forward:
Extensions overwrite semanticsFunctions and Operations can be overwritten. The precedence is based on th order of imports. Functions from later declared imports overwrite functions introduced before. Local functions overwrite imported functions. Consider overwriting the toString() Operation (which is invoked on String concatenations) for arbitrary meta types. This will allow very readable templates. Sticky ExtensionsExtensions are accessible with a static scope. Unfortunately once an object leaves that scope a function (overwriting an operation) is no longer available, so the operation implementation would be used. We need a way to "attach" functions to objects, so that we can effectively "wrap" objects and add new functionality to them. We have two different ideas of how this could be done: 1) adding a stickedTo keyword to the first parameter of an extension: toString(stickedto Entity this) : "foobar"; for each Entity which has been created within a scope where such a sticky extension is declared, the to String() extension will be used for this object. If an object has not been created in such a scope, the sticky function will only be used while the object is in that scope.
TO BE CONTINUED
Code blocksA code block is the replacement for chain expressions ( a-> b-> x) with the additional features:
It's something like a pseudo imperative syntax (but still is an expression!). Variables are assign-once! 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. It is possible to overwrite the scope. Example: doStuff() { var x := "Foo"; { var x:= "Bar"; return x; } } will return "Bar" Object creation expressionWe 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 { name := "Person"; references += new Reference { name := "someRef" type := anotherEntity } } Assignment ExpressionsThey are just another syntax for invoking a setter resp. adder-operation. They return the assigned value. Operator OverloadingThere will be predefined operators which can be used instead of the usual function invocation syntax if there is an operator for a name and a specific number of parameters. Some examples: add(Object a, Object b) => a + b subtract(Object a, Object b) => a- b not(Object a) => !a ...
create / cache semanticsThe creation expression should replace the "create extension" mechanism from Xtend 1.0. A creation of an Object is cached if the type name is suffixed with parenthesis containing any number of arguments. The arguments act as a key. The scope of the caching is per execution context, which can be reused in several invocations? Examples: var paramPerOperationAndName := new Parameter cachedwith op,name { this.name := name; type := aDatatype; } var localSingleton := new Foo cachedwith { stuff := "bla"; } cross referencingWe need a way to specify cross references within a declared tree. The problem is that we need a reference to a created type after it has been created and before it will be initialized. This can be accomplished by adding a special assignment construct: var x := new Entity as localRef { // x is not visible here, because the right hand expression has not been evaluated so far. // localRef holds a reference to the created but not yet initialized entity. name := "Person"; references += new Reference { name := "partner" type := localRef } } XString (Template syntax)We want to come up with a special datatype calle XString, which has a special literal syntax (like Xpand template syntax) and is mutable and streamable. Example: toJava(Entity this) :""" package «packageName()»; public class «name» { «FOREACH attributes AS a» public «a.type» «a.name»; «ENDFOREACH» }"""; It's just a string literal with the xpand syntax within. The terminals '«' and '»' should be configurable (or there should be an alternative at least). The FILE statement will be removed. Files can be opened through extensions: generateCode(Entity e) : writeToFile(e.JavaFile(),e.toJava()); Container (NOT CLEAR HOW THIS COULD WORK)Because XStrings are mutable and are converted to a string late, it is possible to create a tree structure containing XStrings, where you can add XStrings (or normal Strings) later on. Example: toJava(Entity this) :""" package «packageName()»; «imports()» ... """; cached imports(Entity this) :""" import java.util.*; """; ... to be continued (and cleaned up;-))
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. Example: // The following expression will return null: if (false) "Holla" No Checks anymoreChecks used to provide a declarative way of specifying constraints on types. We will come up with a framework to do the same thing, so a constraint can be written like so: import assertion::Extensions; check(Entity this) abstract : error("The abstract entity "+name+" has no subclasses.", subClasses.notEmpty); This would be the replacement for context Entity if abstract ERROR "The abstract entity "+name+" has no subclasses." : subClasses.notEmpty; No big difference I think, but we don't need to introduce a whole new concept (checks). In addition it is now possible to write hierarchicly structured constraints which depend on each other: check(Property this) { dev column := findTable(entity()).columnForName(columnName()); if (error("No corresponding column found ", column!=null) { error("The type does not match", column.type == this.type.sqlType()) } } Moreover one can have a name for a constraint like this (only the 'check' prefix is needed) checkTableExists(Entity this) : error("No corresponding table exists ", findTable(this)!=null); looks and is similar to what xunit does. And it's a good idea to have something like XUnit for our language as well. Definition of Types (later)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; ... }; } } MV: I agree that this is not the most urgent feature. BK added --- To be discussedAdd private keyword to XPandThis is useful for marking Definitions in Xpand-Files as Private-API, especially useful when using AOP-features. Otherwise the whole generator is public API which is not intended in most cases SE: We don't have "Xpand definitions" anymore. We have functions with XString expressions (which look the same). As functions have a private keyword, I think your requirement is met. AOP for ChecksWhen modifying an expression using AOP, there might be the situation that a check is no longer valid. It has to be modified as well SE: We can't modify expressions using AOP. We just can hang an Advice around a function call. I don't understand what you mean by, checks have to be modified. XPandPF added --- to be discussedAdd a FOLDER keywordIn order to create empty directory structures, it would be nice to have a FOLDER keyword. Syntax: «FOLDER expression» |