Skip to main content
Jump to: navigation, search

Difference between revisions of "OAW Roadmap"

(Version 5)
(Redirecting to Oaw)
 
(20 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{| border=0
+
#REDIRECT [[oaw]]
| width=90% |
+
== Overview ==
+
(Insert text here)
+
 
+
== 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
+
                }
+
          }
+
 
+
==== Assignments ====
+
They are just another syntax for invoking a setter resp. adder-operation (which will be removed).
+
 
+
=== 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:
+
 
+
myExtension(String stuff) :
+
    stuff+"-+"stuff;
+
+
context Entity {
+
    javaName() : name.toFirstUpper();
+
    allAttributes() : ....;
+
    stuff(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) and assignments (Expression returning the assigned value)
+
* 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.
+
=== 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;
+
}
+
 
+
 
+
=== 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;
+
                      ...
+
                  };
+
  }
+
}
+
 
+
 
+
 
+
| valign=top |
+
{| border=0 cellspacing=3 cellpadding=4
+
! bgcolor="Gainsboro" | OAW&nbsp;Navigation&nbsp;&nbsp;&nbsp;
+
|-
+
| bgcolor="GhostWhite" | [[OAW| Main Page]]
+
|}
+
|}
+

Latest revision as of 06:29, 9 December 2008

Redirect to:

Back to the top