Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Xcore, xbase and EObject literals
Xcore, xbase and EObject literals [message #716076] Tue, 16 August 2011 11:46 Go to next message
Eclipse UserFriend
Originally posted by:

Hi,

I've been thinking of ways of creating EObjects in Xcore/Xbase. The
simplest way is supporting constructors and make the
compiler/interpreter use the appropriate factory. However, often you
want to create object graphs and that requires a lot of code.

There exists a standard notation for human-readable model instances,
called Human-Understandable Textual Notation (HUTN - see
http://www.omg.org/spec/HUTN/), that could provide a starting point.
Here's a simple example of a library Xcore model, followed by an
instance graph in something HUTN-like.

package no.hal.library

class Book {
BookKind kind
String title
refers Person[*] authors opposite books
}

enum BookKind {
novel, shortStory, fairyTale, play
}

class Person {
boolean author
String name
refers Book[*] books opposite authors
}

class Loan {
refers Book[*] books
refers Person borrower
}

class Library {
contains Book[*] books
contains Person[*] authors
contains Person[*] customers
contains Loan[*] loans
}

// HUTN-like syntax
Library {
books:
Book {
novel
title: "War and Peace"
authors: "Tolstoj"
}
authors:
author Person "Tolstoj" {
name: "Leo Tolstoj"
}
customers:
Person "Hallvard" {
~author
name: "Hallvard Trætteberg"
}
loans: Loan {
books: "War and Peace"
borrower: "Hallvard"
}
}

The syntax allows to create hierarchical structures, with cross
references using STRING IDs. The class name can be omitted, e.g. Book,
when you want an instance of the EReference's type and not a subclass.
There's a shorthand for boolean attributes, the attribute name means
true, prefix with ~ and you negate (e,g. ~author). You can also use an
enum literal directly to set a field typed to the corresponding enum,
e.g. novel above means kind: novel. These two shorthands can be used as
prefixes (adjectives), e.g. author Person. novel Book { ... } would mean
Book { novel } which is the same as Book { kind: novel }. The syntax
includes literals for numbers, characters and Strings and with String
support, all serializable EDataTypes can be supported.

I think this can be useful for Xcore/Xbase in two ways:
- expression syntax, as an extension of Xbase
- textual (file) format for instances, similar to XMI, but
human-write/readable

As an expression syntax, you should be able to include expressions for
attribute/reference values. E.g. you can imagine the following operation
in Library class above (the euro sign is used as a keyword), for adding
a Loan instances:

op void addLoan(Book book, Person borrower) {
val loan = € Loan {
books: book
borrower: borrower
}
loans.add(loan)
}

The operation creates and adds a Loan instance with the books and
borrower references set.

I have implemented the syntax above, and I'm now working on technical
issues related to how to handle this in the compiler/interpreter. I've
been thinking of translating it to another XExpression (a bit like macro
expansion) which when evaluated builds the instance graph, and tricking
the compiler/interpreter into using the alternative XExpression.

Ideas, comments, suggestions?

Hallvard
Re: Xcore, xbase and EObject literals [message #716204 is a reply to message #716076] Tue, 16 August 2011 16:13 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26289
Registered: July 2009
Senior Member
Hallvard,

Comments below.

On 16/08/2011 4:46 AM, Hallvard Trætteberg wrote:
> Hi,
>
> I've been thinking of ways of creating EObjects in Xcore/Xbase. The
> simplest way is supporting constructors and make the
> compiler/interpreter use the appropriate factory.
Yes, we need to discuss this with Sven. It does seem a very natural
approach...
> However, often you want to create object graphs and that requires a
> lot of code.
Calling lots of setters and such, although the notation is more concise
with Xcore, i.e., it looks like assignment to fields.
>
> There exists a standard notation for human-readable model instances,
> called Human-Understandable Textual Notation (HUTN - see
> http://www.omg.org/spec/HUTN/), that could provide a starting point.
> Here's a simple example of a library Xcore model, followed by an
> instance graph in something HUTN-like.
>
> package no.hal.library
>
> class Book {
> BookKind kind
> String title
> refers Person[*] authors opposite books
> }
>
> enum BookKind {
> novel, shortStory, fairyTale, play
> }
>
> class Person {
> boolean author
> String name
> refers Book[*] books opposite authors
> }
>
> class Loan {
> refers Book[*] books
> refers Person borrower
> }
>
> class Library {
> contains Book[*] books
> contains Person[*] authors
> contains Person[*] customers
> contains Loan[*] loans
> }
>
> // HUTN-like syntax
> Library {
> books:
> Book {
> novel
> title: "War and Peace"
> authors: "Tolstoj"
> }
> authors:
> author Person "Tolstoj" {
> name: "Leo Tolstoj"
> }
> customers:
> Person "Hallvard" {
> ~author
> name: "Hallvard Trætteberg"
> }
> loans: Loan {
> books: "War and Peace"
> borrower: "Hallvard"
> }
> }
>
> The syntax allows to create hierarchical structures, with cross
> references using STRING IDs. The class name can be omitted, e.g. Book,
> when you want an instance of the EReference's type and not a subclass.
These names function a bit like xsi:type. I think they'll often need to
be qualified in some way to uniquely identify the model; the types are
not always in the same model as where the feature is defined. It would
be cool if the notation used imports for fully qualified Xcore
classifier names.
> There's a shorthand for boolean attributes, the attribute name means
> true, prefix with ~ and you negate (e,g. ~author). You can also use an
> enum literal directly to set a field typed to the corresponding enum,
> e.g. novel above means kind: novel.
Handy scoping rules...
> These two shorthands can be used as prefixes (adjectives), e.g. author
> Person. novel Book { ... } would mean Book { novel } which is the same
> as Book { kind: novel }. The syntax includes literals for numbers,
> characters and Strings and with String support, all serializable
> EDataTypes can be supported.
Yes that seems relatively straightforward.
>
> I think this can be useful for Xcore/Xbase in two ways:
> - expression syntax, as an extension of Xbase
> - textual (file) format for instances, similar to XMI, but
> human-write/readable
Yes, it would be great if we had a generic syntax for all possible
instances much like XMI but human readable. One thing we talked about
is whether such a notation is more like a literal in some more
expressive language or if it's a purely declarative serialization of the
instance...
>
> As an expression syntax, you should be able to include expressions for
> attribute/reference values. E.g. you can imagine the following
> operation in Library class above (the euro sign is used as a keyword),
> for adding a Loan instances:
>
> op void addLoan(Book book, Person borrower) {
> val loan = € Loan {
> books: book
> borrower: borrower
> }
> loans.add(loan)
> }
>
> The operation creates and adds a Loan instance with the books and
> borrower references set.
Yes, see how quickly one wants a literal syntax.
>
> I have implemented the syntax above, and I'm now working on technical
> issues related to how to handle this in the compiler/interpreter. I've
> been thinking of translating it to another XExpression (a bit like
> macro expansion) which when evaluated builds the instance graph, and
> tricking the compiler/interpreter into using the alternative XExpression.
>
> Ideas, comments, suggestions?
We definitely should discuss these kinds of things with "the Xtext
guys". It would be interesting to define a Json like language, say
Xson, and define a generic mapping from EObject/Ecore to Xson and back
so that it acts like a XMI so that all things could be editable in a
"reflective Xtext" editor...
>
> Hallvard
Re: Xcore, xbase and EObject literals [message #716209 is a reply to message #716076] Tue, 16 August 2011 16:51 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4188
Registered: July 2009
Senior Member
Hi

I think that this functionality is already in MWE2.

Regards

Ed Willink

On 16/08/2011 12:46, Hallvard Trætteberg wrote:
> Hi,
>
> I've been thinking of ways of creating EObjects in Xcore/Xbase. The
> simplest way is supporting constructors and make the
> compiler/interpreter use the appropriate factory. However, often you
> want to create object graphs and that requires a lot of code.
>
> There exists a standard notation for human-readable model instances,
> called Human-Understandable Textual Notation (HUTN - see
> http://www.omg.org/spec/HUTN/), that could provide a starting point.
> Here's a simple example of a library Xcore model, followed by an
> instance graph in something HUTN-like.
>
> package no.hal.library
>
> class Book {
> BookKind kind
> String title
> refers Person[*] authors opposite books
> }
>
> enum BookKind {
> novel, shortStory, fairyTale, play
> }
>
> class Person {
> boolean author
> String name
> refers Book[*] books opposite authors
> }
>
> class Loan {
> refers Book[*] books
> refers Person borrower
> }
>
> class Library {
> contains Book[*] books
> contains Person[*] authors
> contains Person[*] customers
> contains Loan[*] loans
> }
>
> // HUTN-like syntax
> Library {
> books:
> Book {
> novel
> title: "War and Peace"
> authors: "Tolstoj"
> }
> authors:
> author Person "Tolstoj" {
> name: "Leo Tolstoj"
> }
> customers:
> Person "Hallvard" {
> ~author
> name: "Hallvard Trætteberg"
> }
> loans: Loan {
> books: "War and Peace"
> borrower: "Hallvard"
> }
> }
>
> The syntax allows to create hierarchical structures, with cross
> references using STRING IDs. The class name can be omitted, e.g. Book,
> when you want an instance of the EReference's type and not a subclass.
> There's a shorthand for boolean attributes, the attribute name means
> true, prefix with ~ and you negate (e,g. ~author). You can also use an
> enum literal directly to set a field typed to the corresponding enum,
> e.g. novel above means kind: novel. These two shorthands can be used
> as prefixes (adjectives), e.g. author Person. novel Book { ... } would
> mean Book { novel } which is the same as Book { kind: novel }. The
> syntax includes literals for numbers, characters and Strings and with
> String support, all serializable EDataTypes can be supported.
>
> I think this can be useful for Xcore/Xbase in two ways:
> - expression syntax, as an extension of Xbase
> - textual (file) format for instances, similar to XMI, but
> human-write/readable
>
> As an expression syntax, you should be able to include expressions for
> attribute/reference values. E.g. you can imagine the following
> operation in Library class above (the euro sign is used as a keyword),
> for adding a Loan instances:
>
> op void addLoan(Book book, Person borrower) {
> val loan = € Loan {
> books: book
> borrower: borrower
> }
> loans.add(loan)
> }
>
> The operation creates and adds a Loan instance with the books and
> borrower references set.
>
> I have implemented the syntax above, and I'm now working on technical
> issues related to how to handle this in the compiler/interpreter. I've
> been thinking of translating it to another XExpression (a bit like
> macro expansion) which when evaluated builds the instance graph, and
> tricking the compiler/interpreter into using the alternative XExpression.
>
> Ideas, comments, suggestions?
>
> Hallvard
Re: Xcore, xbase and EObject literals [message #716375 is a reply to message #716209] Wed, 17 August 2011 08:26 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by:

On 16.08.11 18.51, Ed Willink wrote:
>
> I think that this functionality is already in MWE2.

Yes, I think you're right (although I at first didn't recognize it as a
generic syntax). The syntax is simular to HUTN's, but I like the latter
better.

I would guess MWE2 is based on Java Beans conventions for the building
process. Ideally, the builder should be able to adapt to various API
conventions. an empty constructor and set is typical and easy, but there
are more patterns for multi-valued features. E.g. to set a feature X to
a list of values you may use a sequence of calls to addX (typical) or
call getX() to get a list and then addAll (ecore).

If the builder is flexible and/or configurable, based on the (inferred)
Jvm model, it may work for POJO's in general and not just ecore.

Hallvard

>
> Regards
>
> Ed Willink
>
> On 16/08/2011 12:46, Hallvard Trætteberg wrote:
>> Hi,
>>
>> I've been thinking of ways of creating EObjects in Xcore/Xbase. The
>> simplest way is supporting constructors and make the
>> compiler/interpreter use the appropriate factory. However, often you
>> want to create object graphs and that requires a lot of code.
>>
>> There exists a standard notation for human-readable model instances,
>> called Human-Understandable Textual Notation (HUTN - see
>> http://www.omg.org/spec/HUTN/), that could provide a starting point.
>> Here's a simple example of a library Xcore model, followed by an
>> instance graph in something HUTN-like.
>>
>> package no.hal.library
>>
>> class Book {
>> BookKind kind
>> String title
>> refers Person[*] authors opposite books
>> }
>>
>> enum BookKind {
>> novel, shortStory, fairyTale, play
>> }
>>
>> class Person {
>> boolean author
>> String name
>> refers Book[*] books opposite authors
>> }
>>
>> class Loan {
>> refers Book[*] books
>> refers Person borrower
>> }
>>
>> class Library {
>> contains Book[*] books
>> contains Person[*] authors
>> contains Person[*] customers
>> contains Loan[*] loans
>> }
>>
>> // HUTN-like syntax
>> Library {
>> books:
>> Book {
>> novel
>> title: "War and Peace"
>> authors: "Tolstoj"
>> }
>> authors:
>> author Person "Tolstoj" {
>> name: "Leo Tolstoj"
>> }
>> customers:
>> Person "Hallvard" {
>> ~author
>> name: "Hallvard Trætteberg"
>> }
>> loans: Loan {
>> books: "War and Peace"
>> borrower: "Hallvard"
>> }
>> }
>>
>> The syntax allows to create hierarchical structures, with cross
>> references using STRING IDs. The class name can be omitted, e.g. Book,
>> when you want an instance of the EReference's type and not a subclass.
>> There's a shorthand for boolean attributes, the attribute name means
>> true, prefix with ~ and you negate (e,g. ~author). You can also use an
>> enum literal directly to set a field typed to the corresponding enum,
>> e.g. novel above means kind: novel. These two shorthands can be used
>> as prefixes (adjectives), e.g. author Person. novel Book { ... } would
>> mean Book { novel } which is the same as Book { kind: novel }. The
>> syntax includes literals for numbers, characters and Strings and with
>> String support, all serializable EDataTypes can be supported.
>>
>> I think this can be useful for Xcore/Xbase in two ways:
>> - expression syntax, as an extension of Xbase
>> - textual (file) format for instances, similar to XMI, but
>> human-write/readable
>>
>> As an expression syntax, you should be able to include expressions for
>> attribute/reference values. E.g. you can imagine the following
>> operation in Library class above (the euro sign is used as a keyword),
>> for adding a Loan instances:
>>
>> op void addLoan(Book book, Person borrower) {
>> val loan = € Loan {
>> books: book
>> borrower: borrower
>> }
>> loans.add(loan)
>> }
>>
>> The operation creates and adds a Loan instance with the books and
>> borrower references set.
>>
>> I have implemented the syntax above, and I'm now working on technical
>> issues related to how to handle this in the compiler/interpreter. I've
>> been thinking of translating it to another XExpression (a bit like
>> macro expansion) which when evaluated builds the instance graph, and
>> tricking the compiler/interpreter into using the alternative XExpression.
>>
>> Ideas, comments, suggestions?
>>
>> Hallvard
>
Re: Xcore, xbase and EObject literals [message #716391 is a reply to message #716375] Wed, 17 August 2011 09:26 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4188
Registered: July 2009
Senior Member
Hi Hallvard

On 17/08/2011 09:26, Hallvard Trætteberg wrote:
> On 16.08.11 18.51, Ed Willink wrote:
>>
>> I think that this functionality is already in MWE2.
>
> Yes, I think you're right (although I at first didn't recognize it as
> a generic syntax). The syntax is simular to HUTN's, but I like the
> latter better.
>
If Xcore is going to ignore inconvenient baggage such as nested
packages, it will either pioneer a new lighter weight EMF2 or cause a
new generation of incompatibility nightmares.

Let's hope for the former, in which case it would be good if the many
Xxxx and related projects shared syntaxes wherever possible. HUTN
belongs in the perhaps bloated UML/OCL/QVT/Acceleo/... OMG camp. Xcore
belongs in the much more pragmatic Xtext/Xpand/Xtend2/MWE2/... stable.

Regards

Ed Willink
Re: Xcore, xbase and EObject literals [message #716424 is a reply to message #716391] Wed, 17 August 2011 11:17 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by:

On 17.08.11 11.26, Ed Willink wrote:
>
> If Xcore is going to ignore inconvenient baggage such as nested
> packages, it will either pioneer a new lighter weight EMF2 or cause a
> new generation of incompatibility nightmares.

Others should answer this, but AFAIU Xcore intentionally omits a syntax
for nested packaged, without considering it's removal from Ecore.

> Let's hope for the former, in which case it would be good if the many
> Xxxx and related projects shared syntaxes wherever possible. HUTN
> belongs in the perhaps bloated UML/OCL/QVT/Acceleo/... OMG camp. Xcore
> belongs in the much more pragmatic Xtext/Xpand/Xtend2/MWE2/... stable.

At this point I think we should let us be inspired by all
attempts/suggestions for a human-readable syntax for object graphics,
without considering their origins. HUTN is fairly simple and clean
(which we both may find surprising, given it's an OMG standard) and if
the Xtext-based implementation also is (which I currently think), I see
it as a good candidate.

Hallvard
Re: Xcore, xbase and EObject literals [message #716597 is a reply to message #716076] Wed, 17 August 2011 19:26 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven EfftingeFriend
Messages: 1771
Registered: July 2009
Senior Member
It was planned to have such an object literal in Xbase but we skipped it
in the first release because other stuff was more important and the
final design didn't feel perfect. It's definitely a very useful
expression (Yes, you should make it an instance of XExpression in your
language).

But it should just reuse expressions as an initializer, so that it is
possible to have all kind of logic there.
You could write something like :

val p = #Person {
name = otherPerson.lastName
firstName = otherPerson.firstName
if (otherPerson.city != null) {
address = # {
city = otherPerson.city
}
}
}

.... you get the idea.

The typeinference is nice and easy to do. The cross referencing however
is a bit trickier and is the main reason why we haven't done it so far.

In Xbase this would definitely be bound to Java objects, which could be
changed for Xcore though.

Cheers,
Sven

Am 8/16/11 1:46 PM, schrieb Hallvard Trætteberg:
> Hi,
>
> I've been thinking of ways of creating EObjects in Xcore/Xbase. The
> simplest way is supporting constructors and make the
> compiler/interpreter use the appropriate factory. However, often you
> want to create object graphs and that requires a lot of code.
>
> There exists a standard notation for human-readable model instances,
> called Human-Understandable Textual Notation (HUTN - see
> http://www.omg.org/spec/HUTN/), that could provide a starting point.
> Here's a simple example of a library Xcore model, followed by an
> instance graph in something HUTN-like.
>
> package no.hal.library
>
> class Book {
> BookKind kind
> String title
> refers Person[*] authors opposite books
> }
>
> enum BookKind {
> novel, shortStory, fairyTale, play
> }
>
> class Person {
> boolean author
> String name
> refers Book[*] books opposite authors
> }
>
> class Loan {
> refers Book[*] books
> refers Person borrower
> }
>
> class Library {
> contains Book[*] books
> contains Person[*] authors
> contains Person[*] customers
> contains Loan[*] loans
> }
>
> // HUTN-like syntax
> Library {
> books:
> Book {
> novel
> title: "War and Peace"
> authors: "Tolstoj"
> }
> authors:
> author Person "Tolstoj" {
> name: "Leo Tolstoj"
> }
> customers:
> Person "Hallvard" {
> ~author
> name: "Hallvard Trætteberg"
> }
> loans: Loan {
> books: "War and Peace"
> borrower: "Hallvard"
> }
> }
>
> The syntax allows to create hierarchical structures, with cross
> references using STRING IDs. The class name can be omitted, e.g. Book,
> when you want an instance of the EReference's type and not a subclass.
> There's a shorthand for boolean attributes, the attribute name means
> true, prefix with ~ and you negate (e,g. ~author). You can also use an
> enum literal directly to set a field typed to the corresponding enum,
> e.g. novel above means kind: novel. These two shorthands can be used as
> prefixes (adjectives), e.g. author Person. novel Book { ... } would mean
> Book { novel } which is the same as Book { kind: novel }. The syntax
> includes literals for numbers, characters and Strings and with String
> support, all serializable EDataTypes can be supported.
>
> I think this can be useful for Xcore/Xbase in two ways:
> - expression syntax, as an extension of Xbase
> - textual (file) format for instances, similar to XMI, but
> human-write/readable
>
> As an expression syntax, you should be able to include expressions for
> attribute/reference values. E.g. you can imagine the following operation
> in Library class above (the euro sign is used as a keyword), for adding
> a Loan instances:
>
> op void addLoan(Book book, Person borrower) {
> val loan = € Loan {
> books: book
> borrower: borrower
> }
> loans.add(loan)
> }
>
> The operation creates and adds a Loan instance with the books and
> borrower references set.
>
> I have implemented the syntax above, and I'm now working on technical
> issues related to how to handle this in the compiler/interpreter. I've
> been thinking of translating it to another XExpression (a bit like macro
> expansion) which when evaluated builds the instance graph, and tricking
> the compiler/interpreter into using the alternative XExpression.
>
> Ideas, comments, suggestions?
>
> Hallvard


--
Need professional support for Xtext or other Eclipse Modeling technologies?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : http://blog.efftinge.de


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: Xcore, xbase and EObject literals [message #716618 is a reply to message #716597] Wed, 17 August 2011 21:32 Go to previous messageGo to next message
Sebastian Benz is currently offline Sebastian BenzFriend
Messages: 24
Registered: July 2009
Junior Member
Hello Hallvard,

I really like the idea of having such object literals. I went into a similiar direction with EFactory (here is a screenshot of the latest syntax: http://twitpic.com/1tl7d9 ). One problem that I think is hard to solve is how to reference entities that do not have a name feature. This would require the possibility to express references as queries, which speaks against a purely declarative serialization format.

In my opinion, such object literals should become part of Xbase as they would be handy in a lot of scenarios.

Regards,

Sebastian


Re: Xcore, xbase and EObject literals [message #716625 is a reply to message #716597] Wed, 17 August 2011 22:04 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by:

On 17.08.11 21.26, Sven Efftinge wrote:
>
> But it should just reuse expressions as an initializer, so that it is
> possible to have all kind of logic there.
> You could write something like :
>
> val p = #Person {
> name = otherPerson.lastName
> firstName = otherPerson.firstName
> if (otherPerson.city != null) {
> address = # {
> city = otherPerson.city
> }
> }
> }
>
> ... you get the idea.

Yes, but there is a balance between readability and freedom. If you can
write anything, it will be difficult to spot the actual field
assignments. And the purpose of a special syntax, is making the
important things easier to read and write.

A very verbose part of creating an object graph is setting multi-valued
features, so having special syntax for values lists is nice. You can
choose to allow the value list syntax in special places or invent a list
creation operator to use with assignment (could be useful in general).

Unfortunately, it is also dependent on the API design. E.g. you can
- set the whole list with setElements(newList(x, y, z)),
- use add as in addElement(x); addElement(y); addElement(z) or
- get the list and use addAll as in getElements().addAll(newList(x, y, z)).
So, although interpreting address = ... as setAddress is
uncontroversial, multi-valued features have no simple rule. You may have
to have to support pluggable providers pr. class/feature.

> The cross referencing however
> is a bit trickier and is the main reason why we haven't done it so far.

Yes, wiring objects things together in the correct order requires being
able to (re)order creation and feature initialization, e.g. create all
objects first, and then executing the inits. That will be difficult if
you mix in ifs and such. You may need a general mechanism for detecting
the reading of uninitialized values and delaying/queuing the execution.

Hallvard
Re: Xcore, xbase and EObject literals [message #716687 is a reply to message #716625] Thu, 18 August 2011 05:30 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4188
Registered: July 2009
Senior Member
Hi

Lists and references; interesting.

OCL currently has an outstanding
https://bugs.eclipse.org/bugs/show_bug.cgi?id=293622 and OMG issue to
add type constructors.

Lists and such-like are easy in OCL because there are Set{...},
Sequence{...}, OrderedSet{...} and Bag{...} constructors
in which arbitrary iterations can contribute. Xcore might benefit from
similar List constructors.

I had not considered references to construct graphs rather than trees.

Currently in OCL specifications, the lack of type construction is worked
around by
- a 'make' method which
- hypothesizes the existence of the required object
- imposes validity constraints to 'assign' to the hypothesized object

This approach might work for Xcore:

Let the primary X { y= ... } syntax support construction of an object
tree (attributes and
containment references), then let a subsequent
equivalence/post-condition/assignment
clauses use navigation expressions to define/constrain the
non-containment references.

If you want to avoid the complexity in the navigation expressions this
can be a two-pass
algorithm, with perhaps #n introducing a temporary name for use in pass 2.

A {/*pass1*/ a = 1; b1 = B#x1 {...} b2 = B#x2{...} } {/*pass2*/ x1.b =
x2; x2.b = x1; }

Regards

Ed Willink

On 17/08/2011 23:04, Hallvard Trætteberg wrote:
> On 17.08.11 21.26, Sven Efftinge wrote:
>>
>> But it should just reuse expressions as an initializer, so that it is
>> possible to have all kind of logic there.
>> You could write something like :
>>
>> val p = #Person {
>> name = otherPerson.lastName
>> firstName = otherPerson.firstName
>> if (otherPerson.city != null) {
>> address = # {
>> city = otherPerson.city
>> }
>> }
>> }
>>
>> ... you get the idea.
>
> Yes, but there is a balance between readability and freedom. If you
> can write anything, it will be difficult to spot the actual field
> assignments. And the purpose of a special syntax, is making the
> important things easier to read and write.
>
> A very verbose part of creating an object graph is setting
> multi-valued features, so having special syntax for values lists is
> nice. You can choose to allow the value list syntax in special places
> or invent a list creation operator to use with assignment (could be
> useful in general).
>
> Unfortunately, it is also dependent on the API design. E.g. you can
> - set the whole list with setElements(newList(x, y, z)),
> - use add as in addElement(x); addElement(y); addElement(z) or
> - get the list and use addAll as in getElements().addAll(newList(x, y,
> z)).
> So, although interpreting address = ... as setAddress is
> uncontroversial, multi-valued features have no simple rule. You may
> have to have to support pluggable providers pr. class/feature.
>
>> The cross referencing however
>> is a bit trickier and is the main reason why we haven't done it so far.
>
> Yes, wiring objects things together in the correct order requires
> being able to (re)order creation and feature initialization, e.g.
> create all objects first, and then executing the inits. That will be
> difficult if you mix in ifs and such. You may need a general mechanism
> for detecting the reading of uninitialized values and delaying/queuing
> the execution.
>
> Hallvard
Re: Xcore, xbase and EObject literals [message #716714 is a reply to message #716618] Thu, 18 August 2011 08:04 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by:

On 17.08.11 23.32, Sebastian Benz wrote:
> Hello Hallvard,
>
> I really like the idea of having such object literals. I went into a
> similiar direction with
> http://code.google.com/a/eclipselabs.org/p/efactory/ (here is a
> screenshot of the latest syntax: http://twitpic.com/1tl7d9 ).

Your syntax seems to be similar to Sven's suggestion. There are several
issues that should be discussed separately:

- Scoping of initializers: An advantage of all proposals is the implicit
scope of the initialization block, similar to Pascal's (!) with
statement: with (<expr>) { ... } evaluates <expr> and executes the block
in the scope of <expr>'s features. I like the way you generalize new to
be (optionally) followed by such a with-block.

- Assignment of multi-valued features. You can use ordinary assignment,
and hence can use += for adding, whereas HUTN has a special value list
syntax, which is simpler for longer lists. These can be combined, just
by introducing a Collection constructor syntax (perhaps ala OCL), since
+= already is interpreted as addAll (CollectionExtension.java).

- Handling cross-references: This is problematic both syntax-wise and
execution-wise. You can allow a name for all creations or use val obj =
with val being added to the outermost scope that is not an object
creation. (Common Lisp's reader syntax allows creating graphs, with #n=
used to capture an object and #n# to ref to it). You can split the
syntax and process in two, creation and cross-referencing, or you can
allow the mechanism to reorder creation/initialization to satisfy
ordering constraints.

After seeing your proposal, my opinion is the following:
- Generalize new to be followed by a with block
- Introduce a syntax for creating various kinds of Collections
- Make val bind to the outermost new, to capture creations for
cross-referencing
- Allow the order of creation and assignments to be changed. This may
require allowing only assignments at the top-level in the with-blocks.

Hope this helps to structure the discussion.

Hallvard

P.S. It's possible to generalize with-blocks to all expressions, i.e.
allow <expr> { ... }. This would mean evaluate <expr>, then the block in
the scope of <expr> and finally use the value of <expr>. You could also
generalize dot in the same way, i.e. allow <expr>.{...}. The only
difference would be that the value of this construct as a whole is the
value of the block and not <expr>.
Re: Xcore, xbase and EObject literals [message #717056 is a reply to message #716687] Fri, 19 August 2011 07:26 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven EfftingeFriend
Messages: 1771
Registered: July 2009
Senior Member
> Lists and such-like are easy in OCL because there are Set{...},
> Sequence{...}, OrderedSet{...} and Bag{...} constructors
> in which arbitrary iterations can contribute. Xcore might benefit from
> similar List constructors.

The Xbase library comes with functions for that:

newArrayList(a, b, c)
newHashMap( 1 -> a, 2 -> b, 3 -> c)

just based on static imports and var args (and in the case of maps also operator overloading).
Defining your own functions for special collection types (e.g. EList) is very easy.

Sven


--
Need professional support on Xtext or Xtend?
Mail to: xtext (at) itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: Xcore, xbase and EObject literals [message #717161 is a reply to message #717056] Fri, 19 August 2011 13:20 Go to previous message
Eclipse UserFriend
Originally posted by:

On 19.08.11 09.26, Sven Efftinge wrote:
>> Lists and such-like are easy in OCL because there are Set{...},
>> Sequence{...}, OrderedSet{...} and Bag{...} constructors
>> in which arbitrary iterations can contribute. Xcore might benefit from
>> similar List constructors.
>
> The Xbase library comes with functions for that:
>
> newArrayList(a, b, c)
> newHashMap( 1 -> a, 2 -> b, 3 -> c)
>
> just based on static imports and var args (and in the case of maps also
> operator overloading).
> Defining your own functions for special collection types (e.g. EList) is
> very easy.

Some extra info: The class StaticMethodsFeatureForTypeProvider hooks two
kinds of classes into the Xbase framework:

1) Extension classes may contain methods that are transparently added to
existing Java classes. E.g. in Xbase you can call list.reverse(),
because the ListExtensions class has a method reverse(List) and this
class is defined to extend java.util.List. Inheritance is supported, so
the methods in CollectionExtensions may be called on Collection and List
instances, since a List is also a Collection.

2) Literal classes provide global functions like println and
newArrayList. There are classes for IO and creating collections.

In addition, Xbase implements operators by means of a mapping from
operator to/from method name (see OperatorMapping class). This means you
can support most operators by implementing the corresponding method in
an extension class. E.g. to support + you must implement operator_plus,
to support += implement operator_add.

Finally, to extend the extensions, you can implement your own
StaticMethodsFeatureForTypeProvider-like class, and add (or remove)
other extension and literal classes. You can even define new operators
with a mapping to an extension method, if you implement your own
OperatorMapping-like class. In both cases, you must wire in your classes
in your language's DslRuntimeModule class. I've tried adding both
extension methods and operators using these techniques and it worked well!

Hallvard
Previous Topic:problem with deploying plugin developed by xtext
Next Topic:Xtext builder: skip processing resource
Goto Forum:
  


Current Time: Mon Dec 22 10:04:17 GMT 2014

Powered by FUDForum. Page generated in 0.02225 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software