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?

> 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

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

> 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.

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

> 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...

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 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).