Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Modeling (top-level project) » generics in ecore model
generics in ecore model [message #641814] Sun, 28 November 2010 11:41 Go to next message
Stephan Zehrer is currently offline Stephan ZehrerFriend
Messages: 42
Registered: July 2009
Member
Hi

two questions regarding the ecore model at the end.

It defines two classed using generic.

The Class BasicElement works fine, just as an example what it should do.

The class BasicElement implements the java generic Comparable interfaces. It is comparable with other BasicElements. Therefore it hold a value of a generic type "T".
If you just generate this part it work's fine.

But would it be better if this generic T type implementes the Comparable interfaces too?

I tried this with the class Element, which restrict the type with a EGeneric Bound Type.

But if you generate this there is a compiler error in "GenericFactoryImpl".

Q1: What did i wrong?

I put the Comparable interface in a separate package (for a reason), now a Factory and Package class is generated, even this package is empty.

Q2: Is saw no switch to disable the generation of those classes, is it possible to disable this?

Thx

Stephan

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="test"
    nsURI="http://zehrer.net/test" nsPrefix="zt">
  <eSubpackages name="generic" nsURI="http://zehrer.net/test/generics" nsPrefix="ztg">
    <eClassifiers xsi:type="ecore:EClass" name="BasicElement">
      <eTypeParameters name="T"/>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="value">
        <eGenericType eTypeParameter="#//generic/BasicElement/T"/>
      </eStructuralFeatures>
      <eGenericSuperTypes eClassifier="#//lang/Comparable">
        <eTypeArguments eClassifier="#//generic/BasicElement"/>
      </eGenericSuperTypes>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="Element">
      <eTypeParameters name="T">
        <eBounds eClassifier="#//lang/Comparable">
          <eTypeArguments eTypeParameter="#//generic/Element/T"/>
        </eBounds>
      </eTypeParameters>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="value">
        <eGenericType eTypeParameter="#//generic/Element/T"/>
      </eStructuralFeatures>
      <eGenericSuperTypes eClassifier="#//lang/Comparable">
        <eTypeArguments eClassifier="#//generic/Element">
          <eTypeArguments eTypeParameter="#//generic/Element/T"/>
        </eTypeArguments>
      </eGenericSuperTypes>
    </eClassifiers>
  </eSubpackages>
  <eSubpackages name="lang" nsURI="http://zehrer.net/test/lang" nsPrefix="ztl">
    <eClassifiers xsi:type="ecore:EClass" name="Comparable" instanceClassName="java.lang.Comparable"
        abstract="true" interface="true">
      <eTypeParameters name="T"/>
      <eOperations name="compareTo" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt">
        <eParameters name="other">
          <eGenericType eTypeParameter="#//lang/Comparable/T"/>
        </eParameters>
      </eOperations>
    </eClassifiers>
  </eSubpackages>
</ecore:EPackage>


Or download here:
http://code.google.com/p/nakedobject2/source/browse/net.zehr er.test/model/generics.ecore
Re: generics in ecore model [message #641844 is a reply to message #641814] Sun, 28 November 2010 17:24 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26237
Registered: July 2009
Senior Member
Stephan,

Comments below.

Stephan Zehrer wrote:
> Hi
>
> two questions regarding the ecore model at the end.
>
> It defines two classed using generic.
> The Class BasicElement works fine, just as an example what it should do.
>
> The class BasicElement implements the java generic Comparable
> interfaces. It is comparable with other BasicElements. Therefore it
> hold a value of a generic type "T".
> If you just generate this part it work's fine.
>
> But would it be better if this generic T type implementes the
> 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? Keep in mind
the symmetric nature of compare, i.e., that you need to be able to
compare x to y and vice versa and have them produce consistent results.
Typically that means they have to be of exactly the same type....
>
> I tried this with the class Element, which restrict the type with a
> EGeneric Bound Type.
>
> But if you generate this there is a compiler error in
> "GenericFactoryImpl".
>
> 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....
>
> I put the Comparable interface in a separate package (for a reason),
> now a Factory and Package class is generated, even this package is empty.
>
> 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.
> Thx
>
> Stephan
>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="test"
> nsURI="http://zehrer.net/test" nsPrefix="zt">
> <eSubpackages name="generic" nsURI="http://zehrer.net/test/generics"
> nsPrefix="ztg">
> <eClassifiers xsi:type="ecore:EClass" name="BasicElement">
> <eTypeParameters name="T"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="value">
> <eGenericType eTypeParameter="#//generic/BasicElement/T"/>
> </eStructuralFeatures>
> <eGenericSuperTypes eClassifier="#//lang/Comparable">
> <eTypeArguments eClassifier="#//generic/BasicElement"/>
> </eGenericSuperTypes>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Element">
> <eTypeParameters name="T">
> <eBounds eClassifier="#//lang/Comparable">
> <eTypeArguments eTypeParameter="#//generic/Element/T"/>
> </eBounds>
> </eTypeParameters>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="value">
> <eGenericType eTypeParameter="#//generic/Element/T"/>
> </eStructuralFeatures>
> <eGenericSuperTypes eClassifier="#//lang/Comparable">
> <eTypeArguments eClassifier="#//generic/Element">
> <eTypeArguments eTypeParameter="#//generic/Element/T"/>
> </eTypeArguments>
> </eGenericSuperTypes>
> </eClassifiers>
> </eSubpackages>
> <eSubpackages name="lang" nsURI="http://zehrer.net/test/lang"
> nsPrefix="ztl">
> <eClassifiers xsi:type="ecore:EClass" name="Comparable"
> instanceClassName="java.lang.Comparable"
> abstract="true" interface="true">
> <eTypeParameters name="T"/>
> <eOperations name="compareTo" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EInt">
> <eParameters name="other">
> <eGenericType eTypeParameter="#//lang/Comparable/T"/>
> </eParameters>
> </eOperations>
> </eClassifiers>
> </eSubpackages>
> </ecore:EPackage>
>
>
> Or download here:
> http://code.google.com/p/nakedobject2/source/browse/net.zehr er.test/model/generics.ecore
>
Re: generics in ecore model [message #641862 is a reply to message #641844] Sun, 28 November 2010 21:32 Go to previous messageGo to next message
Stephan Zehrer is currently offline Stephan ZehrerFriend
Messages: 42
Registered: July 2009
Member
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 pure java but the idea was to bring it to emf. There i run this problem.

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

here my the original definition from the java class (link) above :

public class Interval<T extends Comparable<T>> implements Comparable<Interval<T>>


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.

Thx

Stephan
Re: generics in ecore model [message #641865 is a reply to message #641862] Sun, 28 November 2010 22:25 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26237
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
Re: generics in ecore model [message #642106 is a reply to message #641865] Mon, 29 November 2010 20:51 Go to previous messageGo to next message
Stephan Zehrer is currently offline Stephan ZehrerFriend
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 Smile
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26237
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
Re: generics in ecore model [message #642343 is a reply to message #642122] Tue, 30 November 2010 21:11 Go to previous messageGo to next message
Stephan Zehrer is currently offline Stephan ZehrerFriend
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. Razz 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
Re: generics in ecore model [message #642575 is a reply to message #642343] Wed, 01 December 2010 19:52 Go to previous message
Stephan Zehrer is currently offline Stephan ZehrerFriend
Messages: 42
Registered: July 2009
Member
Stephan Zehrer wrote on Tue, 30 November 2010 16:11

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.

I've been thinking what you said.
At the moment I would not prefer to define it as an immutable because you don't know all the use cases yet. e.g in my case I do a bit "research" on a semantic editor.
I was looking on XText but the concept does not fit.
But the central model (AbstractNode/CompositeNode/LeafNode) is not so bad (even if the implementation IHMO is improvable).
The node's are nothing else as intervals and therefor you can implement many operations with standard intervall methods.
But in this case I think immutable would not be the best solution because just for a simple update of the document many lead to many node's changes. (they store the offset of the text).
Previous Topic:EMF : get Eclass from ClassifierID
Next Topic:how to adapt the generated objectsI have
Goto Forum:
  


Current Time: Fri Nov 28 19:42:05 GMT 2014

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

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