Home » Modeling » Modeling (top-level project) » generics in ecore model
| | |
Re: generics in ecore model [message #641865 is a reply to message #641862] |
Sun, 28 November 2010 22:25 |
Ed Merks Messages: 33216 Registered: July 2009 |
Senior Member |
|
|
Stephan,
Comments below.
Stephan Zehrer wrote:
> Ed Merks wrote on Sun, 28 November 2010 12:24
>> > Comparable interfaces too?
>> Are you trying to define a container to hold values and have the
>> container define how they are compared or are you expecting the
>> contained values themselves to define how to be compared?
>
> Both the container should be comparable and to simplify the
> implementation the values of the container should be comparable to.
> But this is not the issue here.
> With this example I just build a minimum setup to where i run into the
> problem.
>
> My real life problem already exist in
> http://code.google.com/p/nakedobject2/source/browse/net.zehr er.common/src/com/domainlanguage/interval/Interval.java
> but the idea was to bring it to emf. There i run this problem.
Should that thing really be modeled as an EClass though?
At this point I have no idea what one would need to write in Java to
save the result of createElement in a variable. Do you have any ideas?
> Ed Merks wrote on Sun, 28 November 2010 12:24
>> > Q1: What did i wrong?
>> I'm not sure what type could ever satisfy the constraints the bounds
>> specify. The compiler seems unable to defer such a thing....
>
> All standard object types of java, e.g the java.lang.Integer class
> implements the comparable interface. The definition just request a
> type which is comparable
They're all final and aren't themselves generic though.
>
> here my the original definition from the java class (link) above :
>
> public class Interval<T extends Comparable<T>> implements
> Comparable<Interval<T>>
It's a class, not an interface though... You might want to model it as
an EDataType instead...
>
> Ed Merks wrote on Sun, 28 November 2010 12:24
>> > Q2: Is saw no switch to disable the generation of those classes, is
>> it > possible to disable this?
>> You can mark the EClasses as abstract or even to mark them as
>> interfaces.
>
>
> They are marked as interface and abstract, nevertheless the package
> and the factory class is generated.
No, the Element EClass has abstract and interface as false. If abstract
were true, the generated Impl would be abstract and there'd be no
factory method to create it (and hence no problem in the generated
factory Impl). If interface were true, there wouldn't even be a
generated Impl.
I suspect that in the end, it doesn't make sense to create an instance
without T being explicitly bound. There's no way to determine T via
reflection given just an Element instance (except of course if there is
a derived EClass that extends Element which binds T as part of the
derivation)...
>
> Thx
>
> Stephan
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: generics in ecore model [message #642106 is a reply to message #641865] |
Mon, 29 November 2010 20:51 |
Stephan Zehrer Messages: 42 Registered: July 2009 |
Member |
|
|
Hi Ed,
first thx for you comments.
Ed Merks wrote on Sun, 28 November 2010 17:25 |
> My real life problem already exist in Interval.java
> but the idea was to bring it to emf. There i run this problem.
Should that thing really be modeled as an EClass though?
|
Well this is quite a different question.
I did not expect from you
Yes you maybe right, such "simple" stuff like a Interval is not worth to implement as an EClass.
So what is worth and was not?
Ed Merks wrote on Sun, 28 November 2010 17:25 |
At this point I have no idea what one would need to write in Java to
save the result of createElement in a variable. Do you have any ideas?
|
Sorry you talking now about the Interval or the Element sample?
(As i wrote the element class was just a example.
The interval has to generic variables upper/lower boundary. )
Ed Merks wrote on Sun, 28 November 2010 17:25 |
>> > Q2: Is saw no switch to disable the generation of those classes, is
>> it > possible to disable this?
>> You can mark the EClasses as abstract or even to mark them as
>> interfaces.
No, the Element EClass has abstract and interface as false. If abstract
were true, the generated Impl would be abstract and there'd be no
factory method to create it (and hence no problem in the generated
factory Impl). If interface were true, there wouldn't even be a
generated Impl.
|
The second question was related to the comparable interface in the package lang.
For this I get a LangFactory (with a more or less empty create methode) and a LangPackage.
Ed Merks wrote on Sun, 28 November 2010 17:25 |
I suspect that in the end, it doesn't make sense to create an instance
without T being explicitly bound. There's no way to determine T via
reflection given just an Element instance (except of course if there is
a derived EClass that extends Element which binds T as part of the
derivation)...
|
This is the idea, but there is the next problem, if i try to bind the T to e.g. an Integer Class or EIntegerObject
I get a error something about "not valid substitution". Seems he know's nothing about the comparable interface.
Greetings from Germany
Stephan
|
|
|
Re: generics in ecore model [message #642122 is a reply to message #642106] |
Mon, 29 November 2010 21:54 |
Ed Merks Messages: 33216 Registered: July 2009 |
Senior Member |
|
|
Stephan,
Comments below.
Stephan Zehrer wrote:
> Hi Ed,
>
> first thx for you comments.
>
> Ed Merks wrote on Sun, 28 November 2010 17:25
>> > My real life problem already exist in Interval.java
>> > but the idea was to bring it to emf. There i run this problem.
>> Should that thing really be modeled as an EClass though?
>
> Well this is quite a different question. I did not expect from you :)
> Yes you maybe right, such "simple" stuff like a Interval is not worth
> to implement as an EClass. So what is worth and was not?
In the GMF Notation model, they modeled things like Point; I think it
would have been better as an immutable data type...
>
> Ed Merks wrote on Sun, 28 November 2010 17:25
>> At this point I have no idea what one would need to write in Java to
>> save the result of createElement in a variable. Do you have any ideas?
>
> Sorry you talking now about the Interval or the Element sample?
The Element sample. I.e., the call to create needs to return something
that's an EObject, but I really have no idea what Java code one would
write. Even the compiler doesn't seem to be able to infer a correct
solution...
> (As i wrote the element class was just a example. The interval has to
> generic variables upper/lower boundary. )
>
> Ed Merks wrote on Sun, 28 November 2010 17:25
>> >> > Q2: Is saw no switch to disable the generation of those classes,
>> is >> it > possible to disable this?
>> >> You can mark the EClasses as abstract or even to mark them as >>
>> interfaces.
>>
>> No, the Element EClass has abstract and interface as false. If
>> abstract were true, the generated Impl would be abstract and there'd
>> be no factory method to create it (and hence no problem in the
>> generated factory Impl). If interface were true, there wouldn't even
>> be a generated Impl.
>
> The second question was related to the comparable interface in the
> package lang.
> For this I get a LangFactory (with a more or less empty create
> methode) and a LangPackage.
And little bit less. :-P There is the meta data for the Comparable
EDataType...
>
> Ed Merks wrote on Sun, 28 November 2010 17:25
>> I suspect that in the end, it doesn't make sense to create an
>> instance without T being explicitly bound. There's no way to
>> determine T via reflection given just an Element instance (except of
>> course if there is a derived EClass that extends Element which binds
>> T as part of the derivation)...
>
> This is the idea, but there is the next problem, if i try to bind the
> T to e.g. an Integer Class or EIntegerObject
> I get a error something about "not valid substitution". Seems he
> know's nothing about the comparable interface.
Oh. That's not good. With an EDataType, EMF can't know whether it's
valid with respect to the bound so it should assume it's valid. Please
open a bugzilla with that case...
Note that you can still generate the code even when you have this error
(you can turn to the Generator tab for that). If you make Element
abstract you won't end up with any syntax errors. It's not clear that
it makes sense for Element to be not abstract. You can do things like
Element<Integer> element = <factory>.createElement() but how to express
something where the bound isn't specified. as is needed in the create()
method? The recursive nature of the bound seems to make that impossible
with a bounded type parameter...
>
> Greetings from Germany
>
> Stephan
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: generics in ecore model [message #642343 is a reply to message #642122] |
Tue, 30 November 2010 21:11 |
Stephan Zehrer Messages: 42 Registered: July 2009 |
Member |
|
|
Hi Ed,
Ed Merks wrote on Mon, 29 November 2010 16:54 |
> Yes you maybe right, such "simple" stuff like a Interval is not worth
> to implement as an EClass. So what is worth and was not?
In the GMF Notation model, they modeled things like Point; I think it
would have been better as an immutable data type...
|
Well i was thinking of this but first I decided to learn and test the generics feature of
ecore.
Ed Merks wrote on Mon, 29 November 2010 16:54 |
> Sorry you talking now about the Interval or the Element sample?
The Element sample. I.e., the call to create needs to return something
that's an EObject, but I really have no idea what Java code one would
write. Even the compiler doesn't seem to be able to infer a correct
solution...
|
Yes I see now, you can not combine this generics feature and the factory pattern.
The only way is really to define the class abstract.
The nice thing is, it seems I am not the only one having this problem.
Just found this during open the bug from the end of this posting.
Ed Merks wrote on Mon, 29 November 2010 16:54 |
> For this I get a LangFactory (with a more or less empty create
> methode) and a LangPackage.
And little bit less. There is the meta data for the Comparable
EDataType...
|
Ok so the short answer is no cause of meta data
Ed Merks wrote on Mon, 29 November 2010 16:54 |
> This is the idea, but there is the next problem, if i try to bind the
> T to e.g. an Integer Class or EIntegerObject
> I get a error something about "not valid substitution". Seems he
> know's nothing about the comparable interface.
Oh. That's not good. With an EDataType, EMF can't know whether it's
valid with respect to the bound so it should assume it's valid. Please
open a bugzilla with that case...
|
Done see https://bugs.eclipse.org/bugs/show_bug.cgi?id=331475
Ed Merks wrote on Mon, 29 November 2010 16:54 |
Note that you can still generate the code even when you have this error
(you can turn to the Generator tab for that). If you make Element
abstract you won't end up with any syntax errors. It's not clear that
it makes sense for Element to be not abstract. You can do things like
Element<Integer> element = <factory>.createElement() but how to express
something where the bound isn't specified. as is needed in the create()
method? The recursive nature of the bound seems to make that impossible
with a bounded type parameter...
|
yes found same solution.
Thanks Ed
Greetings form the Lake of Constance
Stephan
|
|
| |
Goto Forum:
Current Time: Fri Sep 20 09:02:35 GMT 2024
Powered by FUDForum. Page generated in 0.03362 seconds
|