Whether EClass.abstract is true or false, an implementation class will
be generated and it will be abstract or not accordingly. If there is
no instanceTypeName set, an interface will be generated. Only if
EClass.interface is true is no implementation class generated; abstract
must necessarily be true then as well. In order to support a dynamic
derived EClass of a generated EClass, there must be a non-abstract
implementation class generated for it; the dynamic instance will use
that implementation class. Why? Because the dynamic instance must
properly implement and be castable to all generated interfaces in its
hierarchy.
Cheers,
Ed
yves (yingmin) yang wrote:
a) It looks like there's a Java-Class generated when looking at our
model project.
In EMF, if you model an abstract class without generic type, Java class will
not be generated. I think it is generated because of the generic type.
yves
-----Original Message-----
From: e4-dev-bounces@xxxxxxxxxxx [mailto:e4-dev-bounces@xxxxxxxxxxx] On
Behalf Of Tom Schindl
Sent: Saturday, April 17, 2010 12:56 PM
To: E4 Project developer mailing list
Subject: Re: [e4-dev] New Worklbench model
Hi Hallvard,
a) It looks like there's a Java-Class generated when looking at our
model project.
b) Can you elaborate why you would want to have a dynamic EClass for
e.g. ToolItem if you should creat a DirectToolItem or
HandledToolItem?
Tom
Am 17.04.10 11:46, schrieb Hallvard Trætteberg:
On 17.04.10 05.23, yves (yingmin) yang wrote:
I just noticed several classes become to abstract in workbench model
such as ToolITtem, MenuItem etc. Are they expected?
A quick follow-up: If an EClass is abstract, it cannot be used as the
direct superclass of a *dynamic* EClass, since there will no be
generated a Java class to instantiate. So, even if a class is logically
abstract, it should not always be marked as such.
Hallvard
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
|