Home » Modeling » EMF » [xcore] some problems and fixes
| [xcore] some problems and fixes [message #714346] |
Wed, 10 August 2011 11:37  |
Eclipse User |
|
|
|
Originally posted by:
Hi,
I'm trying out xcore, with the following model:
class Book { ... }
class Person { ... }
class Loan {
refers Book[*] books
refers Person borrower
}
class Library {
contains Book[*] books
contains Loan[*] loans
op void loan(Book[*] books, Person borrower) {
val Loan loan = new Loan();
val List list = new ArrayList();
loan.books.addAll(books);
loan.borrower = borrower;
loans.add(loan);
}
}
I get some error markers in the code, due to some problems with the
mapping from Ecore/GenModel to the Jvm model. In general, multiplicity
is not handled for references or operation parameters. Hence, the type
is not a specialized EList. In addition, the setter of an operation has
an empty argument list and a non-void return type (it seems the code for
inferring the setter is copy paste of the code for inferring the
getter), hence assignment doesn't work.
I've been able to fix this (based on my own project implementing a
similar mapping) and would be happy to share the code.
I also tried to infer a constructor, used in new Loan() above. The idea
is to allow an ordinary constructor call, and make the
compiler/interpreter use the correct EFactory. However, the code from my
own project didn't seem to work, as the JvmConstructor cannot be
resolved. I think it is a problem of associating the JvmConstructor
correctly, since it does seem to be correctly created.
Hallvard
|
|
|
| Re: [xcore] some problems and fixes [message #714403 is a reply to message #714346] |
Wed, 10 August 2011 13:26  |
 Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
On 10/08/2011 4:37 AM, Hallvard Trætteberg wrote:
> Hi,
>
> I'm trying out xcore, with the following model:
>
> class Book { ... }
>
> class Person { ... }
>
> class Loan {
> refers Book[*] books
> refers Person borrower
> }
>
> class Library {
> contains Book[*] books
> contains Loan[*] loans
>
> op void loan(Book[*] books, Person borrower) {
> val Loan loan = new Loan();
> val List list = new ArrayList();
> loan.books.addAll(books);
> loan.borrower = borrower;
> loans.add(loan);
> }
> }
>
> I get some error markers in the code, due to some problems with the
> mapping from Ecore/GenModel to the Jvm model. In general, multiplicity
> is not handled for references or operation parameters.
Oh, that might well be the case... We need to write more tests...
> Hence, the type is not a specialized EList.
Specialized list implementations are used only for structural features...
> In addition, the setter of an operation has an empty argument list and
> a non-void return type (it seems the code for inferring the setter is
> copy paste of the code for inferring the getter), hence assignment
> doesn't work.
Oops. :-P
>
> I've been able to fix this (based on my own project implementing a
> similar mapping) and would be happy to share the code.
Cool. That would be much appreciated. Please use bugzilla for sharing
contributions. We'll need to track contributions to ease the review
process when we pull this back into Eclipse...
>
> I also tried to infer a constructor, used in new Loan() above. The
> idea is to allow an ordinary constructor call, and make the
> compiler/interpreter use the correct EFactory.
Yeah! We are talking about exactly that sort of thing too the other
week, though there was some debate. After all, from a Java point of
view one would be using the generated interface name and only
implementation classes have constructors. But definitely we need (in my
opinion anyway) some form of sugared creation support where you don't
have to specify XyzFactory.eINSTANCE.createAbc but merely need something
like "new Abc".
> However, the code from my own project didn't seem to work, as the
> JvmConstructor cannot be resolved. I think it is a problem of
> associating the JvmConstructor correctly, since it does seem to be
> correctly created.
So far we've not even been inferring an implementation class...
Did you know that Sven's written a test for the interpreter and we can
already eInvoke operations on dynamic instances?
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [xcore] some problems and fixes [message #714404 is a reply to message #714346] |
Wed, 10 August 2011 13:26 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
On 10/08/2011 4:37 AM, Hallvard Trætteberg wrote:
> Hi,
>
> I'm trying out xcore, with the following model:
>
> class Book { ... }
>
> class Person { ... }
>
> class Loan {
> refers Book[*] books
> refers Person borrower
> }
>
> class Library {
> contains Book[*] books
> contains Loan[*] loans
>
> op void loan(Book[*] books, Person borrower) {
> val Loan loan = new Loan();
> val List list = new ArrayList();
> loan.books.addAll(books);
> loan.borrower = borrower;
> loans.add(loan);
> }
> }
>
> I get some error markers in the code, due to some problems with the
> mapping from Ecore/GenModel to the Jvm model. In general, multiplicity
> is not handled for references or operation parameters.
Oh, that might well be the case... We need to write more tests...
> Hence, the type is not a specialized EList.
Specialized list implementations are used only for structural features...
> In addition, the setter of an operation has an empty argument list and
> a non-void return type (it seems the code for inferring the setter is
> copy paste of the code for inferring the getter), hence assignment
> doesn't work.
Oops. :-P
>
> I've been able to fix this (based on my own project implementing a
> similar mapping) and would be happy to share the code.
Cool. That would be much appreciated. Please use bugzilla for sharing
contributions. We'll need to track contributions to ease the review
process when we pull this back into Eclipse...
>
> I also tried to infer a constructor, used in new Loan() above. The
> idea is to allow an ordinary constructor call, and make the
> compiler/interpreter use the correct EFactory.
Yeah! We are talking about exactly that sort of thing too the other
week, though there was some debate. After all, from a Java point of
view one would be using the generated interface name and only
implementation classes have constructors. But definitely we need (in my
opinion anyway) some form of sugared creation support where you don't
have to specify XyzFactory.eINSTANCE.createAbc but merely need something
like "new Abc".
> However, the code from my own project didn't seem to work, as the
> JvmConstructor cannot be resolved. I think it is a problem of
> associating the JvmConstructor correctly, since it does seem to be
> correctly created.
So far we've not even been inferring an implementation class...
Did you know that Sven's written a test for the interpreter and we can
already eInvoke operations on dynamic instances?
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [xcore] some problems and fixes [message #714492 is a reply to message #714403] |
Wed, 10 August 2011 16:36 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Note that I've fixed the inference for the feature setters so they have
a void return type and a parameter for the new value. I've also
improved the interpreter so they invoke eGet/eSet appropriately.
On 10/08/2011 6:26 AM, Ed Merks wrote:
> Hallvard,
>
> Comments below.
>
> On 10/08/2011 4:37 AM, Hallvard Trætteberg wrote:
>> Hi,
>>
>> I'm trying out xcore, with the following model:
>>
>> class Book { ... }
>>
>> class Person { ... }
>>
>> class Loan {
>> refers Book[*] books
>> refers Person borrower
>> }
>>
>> class Library {
>> contains Book[*] books
>> contains Loan[*] loans
>>
>> op void loan(Book[*] books, Person borrower) {
>> val Loan loan = new Loan();
>> val List list = new ArrayList();
>> loan.books.addAll(books);
>> loan.borrower = borrower;
>> loans.add(loan);
>> }
>> }
>>
>> I get some error markers in the code, due to some problems with the
>> mapping from Ecore/GenModel to the Jvm model. In general,
>> multiplicity is not handled for references or operation parameters.
> Oh, that might well be the case... We need to write more tests...
>> Hence, the type is not a specialized EList.
> Specialized list implementations are used only for structural features...
>> In addition, the setter of an operation has an empty argument list
>> and a non-void return type (it seems the code for inferring the
>> setter is copy paste of the code for inferring the getter), hence
>> assignment doesn't work.
> Oops. :-P
>>
>> I've been able to fix this (based on my own project implementing a
>> similar mapping) and would be happy to share the code.
> Cool. That would be much appreciated. Please use bugzilla for
> sharing contributions. We'll need to track contributions to ease the
> review process when we pull this back into Eclipse...
>>
>> I also tried to infer a constructor, used in new Loan() above. The
>> idea is to allow an ordinary constructor call, and make the
>> compiler/interpreter use the correct EFactory.
> Yeah! We are talking about exactly that sort of thing too the other
> week, though there was some debate. After all, from a Java point of
> view one would be using the generated interface name and only
> implementation classes have constructors. But definitely we need (in
> my opinion anyway) some form of sugared creation support where you
> don't have to specify XyzFactory.eINSTANCE.createAbc but merely need
> something like "new Abc".
>> However, the code from my own project didn't seem to work, as the
>> JvmConstructor cannot be resolved. I think it is a problem of
>> associating the JvmConstructor correctly, since it does seem to be
>> correctly created.
> So far we've not even been inferring an implementation class...
>
> Did you know that Sven's written a test for the interpreter and we can
> already eInvoke operations on dynamic instances?
>>
>> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [xcore] some problems and fixes [message #714524 is a reply to message #714403] |
Wed, 10 August 2011 17:29 |
| Eclipse User |
|
|
|
Originally posted by:
On 10.08.11 15.26, Ed Merks wrote:
> Hallvard,
>
>> In general, multiplicity
>> is not handled for references or operation parameters.
> Oh, that might well be the case... We need to write more tests...
>> Hence, the type is not a specialized EList.
> Specialized list implementations are used only for structural features...
I'm thinking of EList<type> in declarations of getters and operation
parameters and return types.
>> I've been able to fix this (based on my own project implementing a
>> similar mapping) and would be happy to share the code.
> Cool. That would be much appreciated. Please use bugzilla for sharing
> contributions. We'll need to track contributions to ease the review
> process when we pull this back into Eclipse...
OK. Any component/tag to use to indicate xcore?
>> I also tried to infer a constructor, used in new Loan() above. The
>> idea is to allow an ordinary constructor call, and make the
>> compiler/interpreter use the correct EFactory.
> Yeah! We are talking about exactly that sort of thing too the other
> week, though there was some debate. After all, from a Java point of view
> one would be using the generated interface name and only implementation
> classes have constructors. But definitely we need (in my opinion anyway)
> some form of sugared creation support where you don't have to specify
> XyzFactory.eINSTANCE.createAbc but merely need something like "new Abc".
>> However, the code from my own project didn't seem to work, as the
>> JvmConstructor cannot be resolved. I think it is a problem of
>> associating the JvmConstructor correctly, since it does seem to be
>> correctly created.
> So far we've not even been inferring an implementation class...
Perhaps the problem is that I infer a constructor for an interface,
which doesn't make sense for Java. I guess the class is filtered out
because it's an interface.
In the context of Xbase, it may actually make sense to allow using new
on an interface, since the compiler/interpreter may be adapted to use a
factory, injector or other means of finding the concrete class to
instantiate.
> Did you know that Sven's written a test for the interpreter and we can
> already eInvoke operations on dynamic instances?
Incredible!
Hallvard
|
|
|
| Re: [xcore] some problems and fixes [message #714532 is a reply to message #714524] |
Wed, 10 August 2011 18:26 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
On 10/08/2011 10:29 AM, Hallvard Trætteberg wrote:
> On 10.08.11 15.26, Ed Merks wrote:
>> Hallvard,
>>
>>> In general, multiplicity
>>> is not handled for references or operation parameters.
>> Oh, that might well be the case... We need to write more tests...
>>> Hence, the type is not a specialized EList.
>> Specialized list implementations are used only for structural
>> features...
>
> I'm thinking of EList<type> in declarations of getters and operation
> parameters and return types.
Yes, we're just using the generic type of the operation/parameter. In
other cases we call GenTypedElement.getType which does the right thing...
>
>>> I've been able to fix this (based on my own project implementing a
>>> similar mapping) and would be happy to share the code.
>> Cool. That would be much appreciated. Please use bugzilla for sharing
>> contributions. We'll need to track contributions to ease the review
>> process when we pull this back into Eclipse...
>
> OK. Any component/tag to use to indicate xcore?
Not yet. We'll need to make that happen...
>
>>> I also tried to infer a constructor, used in new Loan() above. The
>>> idea is to allow an ordinary constructor call, and make the
>>> compiler/interpreter use the correct EFactory.
>> Yeah! We are talking about exactly that sort of thing too the other
>> week, though there was some debate. After all, from a Java point of view
>> one would be using the generated interface name and only implementation
>> classes have constructors. But definitely we need (in my opinion anyway)
>> some form of sugared creation support where you don't have to specify
>> XyzFactory.eINSTANCE.createAbc but merely need something like "new Abc".
>>> However, the code from my own project didn't seem to work, as the
>>> JvmConstructor cannot be resolved. I think it is a problem of
>>> associating the JvmConstructor correctly, since it does seem to be
>>> correctly created.
>> So far we've not even been inferring an implementation class...
>
> Perhaps the problem is that I infer a constructor for an interface,
> which doesn't make sense for Java. I guess the class is filtered out
> because it's an interface.
We've discussed this quite a bit and initially we'd like to avoid doing
things aren't really valid Java... Perhaps we have a special "create"
thing much like "new"...
>
> In the context of Xbase, it may actually make sense to allow using new
> on an interface, since the compiler/interpreter may be adapted to use
> a factory, injector or other means of finding the concrete class to
> instantiate.
It seems intuitive.
>
>> Did you know that Sven's written a test for the interpreter and we can
>> already eInvoke operations on dynamic instances?
>
> Incredible!
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 18 22:59:02 GMT 2024
Powered by FUDForum. Page generated in 0.02125 seconds |
] 
Search
Help
Register
Login
Home
