Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

OAW Roadmap

Revision as of 11:05, 2 March 2007 by Sven.efftinge.typefox.io (Talk | contribs) (Version 5)

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:

new Entity as e {
  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 (
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:

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. The default is "else null".


OAW Navigation   
Main Page

Back to the top