Eclipse Community Forums: EMF » Attribute default value

Help

Home

Home » Modeling » EMF » Attribute default value

Show: Today's Messages :: Show Polls :: Message Navigator

Attribute default value [message #407198]

Sat, 17 February 2007 13:59

Guillaume Brocard
Messages: 25
Registered: July 2009

Junior Member

Hi,

is there any way not to have a default value generated for an attribute ?

For instance, instead of generated code :
/**
* The default value of the '{@link #getId() Id}' attribute.
* 
* 
* @see #getId()
* @generated
* @ordered
*/
protected static final String ID_EDEFAULT = null;

/**
* The cached value of the '{@link #getId() Id}' attribute.
* 
* 
* @see #getId()
* @generated
* @ordered
*/
protected String id = ID_EDEFAULT;

I would have liked a simple :
protected String id;

Even if it does not seem different at first glance, it makes a huge
difference when using a custom root class for generated java class,
especially when trying to fill-up attributes in root class constructor
(using polymorphism on generated operations).

Thanks in advance,
Guillaume.

Report message to a moderator

Re: Attribute default value [message #407201 is a reply to message #407198]

Sat, 17 February 2007 14:20

Ed Merks
Messages: 24562
Registered: July 2009

Senior Member

Guillaume,

No, there's no support for that, at least not yet. Given that the
constructor can change the initial value, why does it make a huge
difference to not have these "default" defaults?

Guillaume wrote:
> Hi,
>
> is there any way not to have a default value generated for an attribute ?
>
> For instance, instead of generated code :
> /**
> * The default value of the '{@link #getId() Id}' attribute.
> * 
> * 
> * @see #getId()
> * @generated
> * @ordered
> */
> protected static final String ID_EDEFAULT = null;
>
> /**
> * The cached value of the '{@link #getId() Id}' attribute.
> * 
> * 
> * @see #getId()
> * @generated
> * @ordered
> */
> protected String id = ID_EDEFAULT;
>
> I would have liked a simple :
> protected String id;
>
> Even if it does not seem different at first glance, it makes a huge
> difference when using a custom root class for generated java class,
> especially when trying to fill-up attributes in root class constructor
> (using polymorphism on generated operations).
>
> Thanks in advance,
> Guillaume.
>
>

Report message to a moderator

Re: Attribute default value [message #407205 is a reply to message #407201]

Sun, 18 February 2007 07:13

Guillaume Brocard
Messages: 25
Registered: July 2009

Junior Member

Ed,

I'll try to explain the situation as clearly as possible.

We had experienced problems with JMerge when developing our data model
using EMF. So we decided to be independent from generated code, separating
hand-coded source folder from generated one.

But we still needed services directly on top of the model.
So we introduced an EMF root class called ModelElement (extending
EObjectImpl to remain consistent).

Moreover, we also experienced difficulties with auto-generated element id
when using provided xml persistence (with several files on disk). So we
introduced a ModelElementWithId top class in our model (all others
extending the latter), which provides EMF with an "ID" tagged attribute
(named id :)).

Eventually, we're having following structure : ModelElement (hand-coded)
<|---- ModelElementWithId (generated).
EMF is generating setId() and getId() methods automatically, which is
great. But also the quoted piece of code about id default value.

But, to go on with our goal, generating an id is to be done in
ModelElement (since it's not subject to JMerge). So ModelElement is
providing with abstract method : public void setId(String ..) (implemented
here by ModelElementWithIdImpl) and a concrete method : protected String
generateId().

And ModelElement constructor implementation does look like :
/**
* Constructor.
*/
public ModelElement() {
// Set id at construction time.
setId(generateId());
...
}

It seems to be the solution. But ModelElementWithIdImpl generated code :
/**
* The default value of the '{@link #getId() Id}' attribute.
* 
* 
* @see #getId()
* @generated
* @ordered
*/
protected static final String ID_EDEFAULT = null;

/**
* The cached value of the '{@link #getId() Id}' attribute.
* 
* 
* @see #getId()
* @generated
* @ordered
*/
protected String id = ID_EDEFAULT;

/**
* 
* 
* @generated
*/
protected ModelElementWithIdImpl() {
super();
}

just erases our generated id with ID_EDEFAULT after exiting its
constructor (default value being executed at this time by java).

We used AspectJ to set the id after initialization of ModelElementWithId.
It worked as intended, but we are now facing a new bug, that is so weird
that we decide to get rid of AspectJ (for testing purposes). And now we
are unable to provide a generated unique id for any model element, and be
independent of generated code at the same time.

Removing ID_EDEFAULT from id declaration line just put things into working
state again, but that relies on JMerge capabilities (as modifying
ModelElementWithIdImpl constructor), which we vowed at first not to use :).

And that's the end of the story, and I hope it helps understanding my
original question.

Guillaume.

Ed Merks wrote:

> Guillaume,

> No, there's no support for that, at least not yet. Given that the
> constructor can change the initial value, why does it make a huge
> difference to not have these "default" defaults?

> Guillaume wrote:
>> Hi,
>>
>> is there any way not to have a default value generated for an attribute ?
>>
>> For instance, instead of generated code :
>> /**
>> * The default value of the '{@link #getId() Id}' attribute.
>> * 
>> * 
>> * @see #getId()
>> * @generated
>> * @ordered
>> */
>> protected static final String ID_EDEFAULT = null;
>>
>> /**
>> * The cached value of the '{@link #getId() Id}' attribute.
>> * 
>> * 
>> * @see #getId()
>> * @generated
>> * @ordered
>> */
>> protected String id = ID_EDEFAULT;
>>
>> I would have liked a simple :
>> protected String id;
>>
>> Even if it does not seem different at first glance, it makes a huge
>> difference when using a custom root class for generated java class,
>> especially when trying to fill-up attributes in root class constructor
>> (using polymorphism on generated operations).
>>
>> Thanks in advance,
>> Guillaume.
>>
>>

Report message to a moderator

Re: Attribute default value [message #407209 is a reply to message #407205]

Sun, 18 February 2007 08:36

Ed Merks
Messages: 24562
Registered: July 2009

Senior Member

Guillaume,

Comments below.

Guillaume wrote:
> Ed,
>
> I'll try to explain the situation as clearly as possible.
>
> We had experienced problems with JMerge when developing our data model
> using EMF. So we decided to be independent from generated code,
> separating hand-coded source folder from generated one.
What kind of problems? We use it ourselves for the development of all
our models and of course many other people use it as well, so any
serious problems I would want to know about and fix.
>
> But we still needed services directly on top of the model.
> So we introduced an EMF root class called ModelElement (extending
> EObjectImpl to remain consistent).
>
> Moreover, we also experienced difficulties with auto-generated element
> id when using provided xml persistence (with several files on disk).
> So we introduced a ModelElementWithId top class in our model (all
> others extending the latter), which provides EMF with an "ID" tagged
> attribute (named id :)).
What kind of problems did you have with auto-generated IDs? UML2 uses
them extensively and hit's used extensively in IBM's products...
>
> Eventually, we're having following structure : ModelElement
> (hand-coded) <|---- ModelElementWithId (generated). EMF is generating
> setId() and getId() methods automatically, which is great. But also
> the quoted piece of code about id default value.
>
> But, to go on with our goal, generating an id is to be done in
> ModelElement (since it's not subject to JMerge). So ModelElement is
> providing with abstract method : public void setId(String ..)
> (implemented here by ModelElementWithIdImpl) and a concrete method :
> protected String generateId().
>
> And ModelElement constructor implementation does look like :
> /**
> * Constructor.
> */
> public ModelElement() {
> // Set id at construction time.
> setId(generateId());
> ...
> }
>
This seems like a bad idea because you will generate an ID during
copying or when creating instances being deserialized and in those
cases, that generated ID will quickly be overwritten by the
copied/deserialized ID.
> It seems to be the solution. But ModelElementWithIdImpl generated code :
> /**
> * The default value of the '{@link #getId() Id}' attribute.
> * 
> * 
> * @see #getId()
> * @generated
> * @ordered
> */
> protected static final String ID_EDEFAULT = null;
>
> /**
> * The cached value of the '{@link #getId() Id}' attribute.
> * 
> * 
> * @see #getId()
> * @generated
> * @ordered
> */
> protected String id = ID_EDEFAULT;
>
> /**
> * 
> * 
> * @generated
> */
> protected ModelElementWithIdImpl() {
> super();
> }
>
> just erases our generated id with ID_EDEFAULT after exiting its
> constructor (default value being executed at this time by java).
I see. But as I said, I don't think generating an ID in the constructor
is a good design approach. It would seem better to generate the ID on
demand by overriding getID to return one rather than null.
>
> We used AspectJ to set the id after initialization of
> ModelElementWithId. It worked as intended, but we are now facing a new
> bug, that is so weird that we decide to get rid of AspectJ (for
> testing purposes). And now we are unable to provide a generated unique
> id for any model element, and be independent of generated code at the
> same time.
>
> Removing ID_EDEFAULT from id declaration line just put things into
> working state again, but that relies on JMerge capabilities (as
> modifying ModelElementWithIdImpl constructor), which we vowed at first
> not to use :).
I really think modifying generated code should be fine and is certainly
done by many many clients.
>
> And that's the end of the story, and I hope it helps understanding my
> original question.
In, 2.3.0, GenFeature has a hasEDefault method that's already used to
guard the generation of the EDefaults, so perhaps we could add a
persistent setting to GenFeature so that the value of hasEDefault can be
explicitly turned off on a feature by feature basis. If you open a
feature request, we'll consider that. The reason I thought you'd give
for wanting this I had thought would be related to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=147952; it actually has a
performance impact to initialize to null rather than just leaving the
field in the Java default state. But you current ID initialization
approach has a much worse performance impact, so you should rethink it...
>
> Guillaume.
>
>
>
> Ed Merks wrote:
>
>> Guillaume,
>
>> No, there's no support for that, at least not yet. Given that the
>> constructor can change the initial value, why does it make a huge
>> difference to not have these "default" defaults?
>
>
>> Guillaume wrote:
>>> Hi,
>>>
>>> is there any way not to have a default value generated for an
>>> attribute ?
>>>
>>> For instance, instead of generated code :
>>> /**
>>> * The default value of the '{@link #getId() Id}' attribute.
>>> * 
>>> * 
>>> * @see #getId()
>>> * @generated
>>> * @ordered
>>> */
>>> protected static final String ID_EDEFAULT = null;
>>>
>>> /**
>>> * The cached value of the '{@link #getId() Id}' attribute.
>>> * 
>>> * 
>>> * @see #getId()
>>> * @generated
>>> * @ordered
>>> */
>>> protected String id = ID_EDEFAULT;
>>>
>>> I would have liked a simple :
>>> protected String id;
>>>
>>> Even if it does not seem different at first glance, it makes a huge
>>> difference when using a custom root class for generated java class,
>>> especially when trying to fill-up attributes in root class
>>> constructor (using polymorphism on generated operations).
>>>
>>> Thanks in advance,
>>> Guillaume.
>>>
>>>
>
>

Report message to a moderator

Re: Attribute default value [message #407223 is a reply to message #407209]

Mon, 19 February 2007 02:42

Guillaume Brocard
Messages: 25
Registered: July 2009

Junior Member

Hi Ed,

thanks for your answers.
You are certainly right about the performance issue.
Again, we used this approach so as to remain independent.

I'll try overriding getId() directly. Still I'm not very found of this
solution, for it forces us to have generated classes in version of
control, and it makes it a bit harder for an external coder to generate
the whole product. But it can be explained in an accompaning document.

As for your bug request, I did not mention it (our model is not really big
so far), but I do agree.

Finally, for the feature request, I'll find it hard justifying it with our
example (which is quite unsatisfying, and about to be changed accordingly
to your comments).

Again, thanks a lot for your swiftness.

Guillaume

PS : for merge issues, it was due to non-deletion of no-longer-designed
classes (making it hard to sort out generated classes from no-longer
ones). For id issues, I'll try to suppress the ID tag on id attribute, and
see what happens.

Ed Merks wrote:

> Guillaume,

> Comments below.

> Guillaume wrote:
>> Ed,
>>
>> I'll try to explain the situation as clearly as possible.
>>
>> We had experienced problems with JMerge when developing our data model
>> using EMF. So we decided to be independent from generated code,
>> separating hand-coded source folder from generated one.
> What kind of problems? We use it ourselves for the development of all
> our models and of course many other people use it as well, so any
> serious problems I would want to know about and fix.
>>
>> But we still needed services directly on top of the model.
>> So we introduced an EMF root class called ModelElement (extending
>> EObjectImpl to remain consistent).
>>
>> Moreover, we also experienced difficulties with auto-generated element
>> id when using provided xml persistence (with several files on disk).
>> So we introduced a ModelElementWithId top class in our model (all
>> others extending the latter), which provides EMF with an "ID" tagged
>> attribute (named id :)).
> What kind of problems did you have with auto-generated IDs? UML2 uses
> them extensively and hit's used extensively in IBM's products...
>>
>> Eventually, we're having following structure : ModelElement
>> (hand-coded) <|---- ModelElementWithId (generated). EMF is generating
>> setId() and getId() methods automatically, which is great. But also
>> the quoted piece of code about id default value.
>>
>> But, to go on with our goal, generating an id is to be done in
>> ModelElement (since it's not subject to JMerge). So ModelElement is
>> providing with abstract method : public void setId(String ..)
>> (implemented here by ModelElementWithIdImpl) and a concrete method :
>> protected String generateId().
>>
>> And ModelElement constructor implementation does look like :
>> /**
>> * Constructor.
>> */
>> public ModelElement() {
>> // Set id at construction time.
>> setId(generateId());
>> ...
>> }
>>
> This seems like a bad idea because you will generate an ID during
> copying or when creating instances being deserialized and in those
> cases, that generated ID will quickly be overwritten by the
> copied/deserialized ID.
>> It seems to be the solution. But ModelElementWithIdImpl generated code :
>> /**
>> * The default value of the '{@link #getId() Id}' attribute.
>> * 
>> * 
>> * @see #getId()
>> * @generated
>> * @ordered
>> */
>> protected static final String ID_EDEFAULT = null;
>>
>> /**
>> * The cached value of the '{@link #getId() Id}' attribute.
>> * 
>> * 
>> * @see #getId()
>> * @generated
>> * @ordered
>> */
>> protected String id = ID_EDEFAULT;
>>
>> /**
>> * 
>> * 
>> * @generated
>> */
>> protected ModelElementWithIdImpl() {
>> super();
>> }
>>
>> just erases our generated id with ID_EDEFAULT after exiting its
>> constructor (default value being executed at this time by java).
> I see. But as I said, I don't think generating an ID in the constructor
> is a good design approach. It would seem better to generate the ID on
> demand by overriding getID to return one rather than null.
>>
>> We used AspectJ to set the id after initialization of
>> ModelElementWithId. It worked as intended, but we are now facing a new
>> bug, that is so weird that we decide to get rid of AspectJ (for
>> testing purposes). And now we are unable to provide a generated unique
>> id for any model element, and be independent of generated code at the
>> same time.
>>
>> Removing ID_EDEFAULT from id declaration line just put things into
>> working state again, but that relies on JMerge capabilities (as
>> modifying ModelElementWithIdImpl constructor), which we vowed at first
>> not to use :).
> I really think modifying generated code should be fine and is certainly
> done by many many clients.
>>
>> And that's the end of the story, and I hope it helps understanding my
>> original question.
> In, 2.3.0, GenFeature has a hasEDefault method that's already used to
> guard the generation of the EDefaults, so perhaps we could add a
> persistent setting to GenFeature so that the value of hasEDefault can be
> explicitly turned off on a feature by feature basis. If you open a
> feature request, we'll consider that. The reason I thought you'd give
> for wanting this I had thought would be related to
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=147952; it actually has a
> performance impact to initialize to null rather than just leaving the
> field in the Java default state. But you current ID initialization
> approach has a much worse performance impact, so you should rethink it...
>>
>> Guillaume.
>>
>>
>>
>> Ed Merks wrote:
>>
>>> Guillaume,
>>
>>> No, there's no support for that, at least not yet. Given that the
>>> constructor can change the initial value, why does it make a huge
>>> difference to not have these "default" defaults?
>>
>>
>>> Guillaume wrote:
>>>> Hi,
>>>>
>>>> is there any way not to have a default value generated for an
>>>> attribute ?
>>>>
>>>> For instance, instead of generated code :
>>>> /**
>>>> * The default value of the '{@link #getId() Id}' attribute.
>>>> * 
>>>> * 
>>>> * @see #getId()
>>>> * @generated
>>>> * @ordered
>>>> */
>>>> protected static final String ID_EDEFAULT = null;
>>>>
>>>> /**
>>>> * The cached value of the '{@link #getId() Id}' attribute.
>>>> * 
>>>> * 
>>>> * @see #getId()
>>>> * @generated
>>>> * @ordered
>>>> */
>>>> protected String id = ID_EDEFAULT;
>>>>
>>>> I would have liked a simple :
>>>> protected String id;
>>>>
>>>> Even if it does not seem different at first glance, it makes a huge
>>>> difference when using a custom root class for generated java class,
>>>> especially when trying to fill-up attributes in root class
>>>> constructor (using polymorphism on generated operations).
>>>>
>>>> Thanks in advance,
>>>> Guillaume.
>>>>
>>>>
>>
>>

Report message to a moderator

Re: Attribute default value [message #407225 is a reply to message #407223]

Mon, 19 February 2007 07:30

Ed Merks
Messages: 24562
Registered: July 2009

Senior Member

Guillaume,

I would personally find it very frustrating to have a repository that
contains code which is not complete (and cannot compile) until you run a
tool to generate the things needed to make it complete. We certainly
commit all our code to CVS and I'm pretty sure most clients take that
approach. I don't see how committing the code makes it harder for
anyone to generate a whole product; in fact, as I said, I think it makes
it easier by not forcing other users to generate the whole product.

People have requested features for far thinner reasons. Since
generating an EDEFAULT that isn't needed has a performance cost, that
fact alone makes it reasonable to request a feature in order to
eliminate a cost when it's not needed. It's quite a trivial thing to
implement. I.e., I can imagine getting it done in far less than an hour
because mostly this involves adding an attribute to GenFeature,
generating the rest, and hooking hasEDefault to return false if this new
attribute is set to false...

Guillaume wrote:
> Hi Ed,
>
> thanks for your answers.
> You are certainly right about the performance issue.
> Again, we used this approach so as to remain independent.
>
> I'll try overriding getId() directly. Still I'm not very found of this
> solution, for it forces us to have generated classes in version of
> control, and it makes it a bit harder for an external coder to
> generate the whole product. But it can be explained in an accompaning
> document.
>
> As for your bug request, I did not mention it (our model is not really
> big so far), but I do agree.
>
> Finally, for the feature request, I'll find it hard justifying it with
> our example (which is quite unsatisfying, and about to be changed
> accordingly to your comments).
>
> Again, thanks a lot for your swiftness.
>
> Guillaume
>
> PS : for merge issues, it was due to non-deletion of
> no-longer-designed classes (making it hard to sort out generated
> classes from no-longer ones). For id issues, I'll try to suppress the
> ID tag on id attribute, and see what happens.
>
>
> Ed Merks wrote:
>
>> Guillaume,
>
>> Comments below.
>
>
>> Guillaume wrote:
>>> Ed,
>>>
>>> I'll try to explain the situation as clearly as possible.
>>>
>>> We had experienced problems with JMerge when developing our data
>>> model using EMF. So we decided to be independent from generated
>>> code, separating hand-coded source folder from generated one.
>> What kind of problems? We use it ourselves for the development of
>> all our models and of course many other people use it as well, so any
>> serious problems I would want to know about and fix.
>>>
>>> But we still needed services directly on top of the model.
>>> So we introduced an EMF root class called ModelElement (extending
>>> EObjectImpl to remain consistent).
>>>
>>> Moreover, we also experienced difficulties with auto-generated
>>> element id when using provided xml persistence (with several files
>>> on disk). So we introduced a ModelElementWithId top class in our
>>> model (all others extending the latter), which provides EMF with an
>>> "ID" tagged attribute (named id :)).
>> What kind of problems did you have with auto-generated IDs? UML2
>> uses them extensively and hit's used extensively in IBM's products...
>>>
>>> Eventually, we're having following structure : ModelElement
>>> (hand-coded) <|---- ModelElementWithId (generated). EMF is
>>> generating setId() and getId() methods automatically, which is
>>> great. But also the quoted piece of code about id default value.
>>>
>>> But, to go on with our goal, generating an id is to be done in
>>> ModelElement (since it's not subject to JMerge). So ModelElement is
>>> providing with abstract method : public void setId(String ..)
>>> (implemented here by ModelElementWithIdImpl) and a concrete method :
>>> protected String generateId().
>>>
>>> And ModelElement constructor implementation does look like :
>>> /**
>>> * Constructor.
>>> */
>>> public ModelElement() {
>>> // Set id at construction time.
>>> setId(generateId());
>>> ...
>>> }
>>>
>> This seems like a bad idea because you will generate an ID during
>> copying or when creating instances being deserialized and in those
>> cases, that generated ID will quickly be overwritten by the
>> copied/deserialized ID.
>>> It seems to be the solution. But ModelElementWithIdImpl generated
>>> code :
>>> /**
>>> * The default value of the '{@link #getId() Id}' attribute.
>>> * 
>>> * 
>>> * @see #getId()
>>> * @generated
>>> * @ordered
>>> */
>>> protected static final String ID_EDEFAULT = null;
>>>
>>> /**
>>> * The cached value of the '{@link #getId() Id}' attribute.
>>> * 
>>> * 
>>> * @see #getId()
>>> * @generated
>>> * @ordered
>>> */
>>> protected String id = ID_EDEFAULT;
>>>
>>> /**
>>> * 
>>> * 
>>> * @generated
>>> */
>>> protected ModelElementWithIdImpl() {
>>> super();
>>> }
>>>
>>> just erases our generated id with ID_EDEFAULT after exiting its
>>> constructor (default value being executed at this time by java).
>> I see. But as I said, I don't think generating an ID in the
>> constructor is a good design approach. It would seem better to
>> generate the ID on demand by overriding getID to return one rather
>> than null.
>>>
>>> We used AspectJ to set the id after initialization of
>>> ModelElementWithId. It worked as intended, but we are now facing a
>>> new bug, that is so weird that we decide to get rid of AspectJ (for
>>> testing purposes). And now we are unable to provide a generated
>>> unique id for any model element, and be independent of generated
>>> code at the same time.
>>>
>>> Removing ID_EDEFAULT from id declaration line just put things into
>>> working state again, but that relies on JMerge capabilities (as
>>> modifying ModelElementWithIdImpl constructor), which we vowed at
>>> first not to use :).
>> I really think modifying generated code should be fine and is
>> certainly done by many many clients.
>>>
>>> And that's the end of the story, and I hope it helps understanding
>>> my original question.
>> In, 2.3.0, GenFeature has a hasEDefault method that's already used to
>> guard the generation of the EDefaults, so perhaps we could add a
>> persistent setting to GenFeature so that the value of hasEDefault can
>> be explicitly turned off on a feature by feature basis. If you open
>> a feature request, we'll consider that. The reason I thought you'd
>> give for wanting this I had thought would be related to
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=147952; it actually has
>> a performance impact to initialize to null rather than just leaving
>> the field in the Java default state. But you current ID
>> initialization approach has a much worse performance impact, so you
>> should rethink it...
>>>
>>> Guillaume.
>>>
>>>
>>>
>>> Ed Merks wrote:
>>>
>>>> Guillaume,
>>>
>>>> No, there's no support for that, at least not yet. Given that the
>>>> constructor can change the initial value, why does it make a huge
>>>> difference to not have these "default" defaults?
>>>
>>>
>>>> Guillaume wrote:
>>>>> Hi,
>>>>>
>>>>> is there any way not to have a default value generated for an
>>>>> attribute ?
>>>>>
>>>>> For instance, instead of generated code :
>>>>> /**
>>>>> * The default value of the '{@link #getId() Id}'
>>>>> attribute.
>>>>> * 
>>>>> * 
>>>>> * @see #getId()
>>>>> * @generated
>>>>> * @ordered
>>>>> */
>>>>> protected static final String ID_EDEFAULT = null;
>>>>>
>>>>> /**
>>>>> * The cached value of the '{@link #getId() Id}' attribute.
>>>>> * 
>>>>> * 
>>>>> * @see #getId()
>>>>> * @generated
>>>>> * @ordered
>>>>> */
>>>>> protected String id = ID_EDEFAULT;
>>>>>
>>>>> I would have liked a simple :
>>>>> protected String id;
>>>>>
>>>>> Even if it does not seem different at first glance, it makes a
>>>>> huge difference when using a custom root class for generated java
>>>>> class, especially when trying to fill-up attributes in root class
>>>>> constructor (using polymorphism on generated operations).
>>>>>
>>>>> Thanks in advance,
>>>>> Guillaume.
>>>>>
>>>>>
>>>
>>>
>

Report message to a moderator

Re: Attribute default value [message #407234 is a reply to message #407225]

Mon, 19 February 2007 10:57

Guillaume Brocard
Messages: 25
Registered: July 2009

Junior Member

Ed,

comments below.

Ed Merks wrote:

> Guillaume,

> I would personally find it very frustrating to have a repository that
> contains code which is not complete (and cannot compile) until you run a
> tool to generate the things needed to make it complete. We certainly
> commit all our code to CVS and I'm pretty sure most clients take that
> approach. I don't see how committing the code makes it harder for
> anyone to generate a whole product; in fact, as I said, I think it makes
> it easier by not forcing other users to generate the whole product.

Well that's something we could argue about.
We have chosen the over approach (automated generation) (see martin fowler
point of view in continuous integration).
Moreover, part of the product is used as a generic framework, and requires
users to get involved in the modeling process.

> People have requested features for far thinner reasons. Since
> generating an EDEFAULT that isn't needed has a performance cost, that
> fact alone makes it reasonable to request a feature in order to
> eliminate a cost when it's not needed. It's quite a trivial thing to
> implement. I.e., I can imagine getting it done in far less than an hour
> because mostly this involves adding an attribute to GenFeature,
> generating the rest, and hooking hasEDefault to return false if this new
> attribute is set to false...

So what should I do ?
Isn't the existing bug report enough ?

> Guillaume wrote:
>> Hi Ed,
>>
>> thanks for your answers.
>> You are certainly right about the performance issue.
>> Again, we used this approach so as to remain independent.
>>
>> I'll try overriding getId() directly. Still I'm not very found of this
>> solution, for it forces us to have generated classes in version of
>> control, and it makes it a bit harder for an external coder to
>> generate the whole product. But it can be explained in an accompaning
>> document.
>>
>> As for your bug request, I did not mention it (our model is not really
>> big so far), but I do agree.
>>
>> Finally, for the feature request, I'll find it hard justifying it with
>> our example (which is quite unsatisfying, and about to be changed
>> accordingly to your comments).
>>
>> Again, thanks a lot for your swiftness.
>>
>> Guillaume
>>
>> PS : for merge issues, it was due to non-deletion of
>> no-longer-designed classes (making it hard to sort out generated
>> classes from no-longer ones). For id issues, I'll try to suppress the
>> ID tag on id attribute, and see what happens.
>>
>>
>> Ed Merks wrote:
>>
>>> Guillaume,
>>
>>> Comments below.
>>
>>
>>> Guillaume wrote:
>>>> Ed,
>>>>
>>>> I'll try to explain the situation as clearly as possible.
>>>>
>>>> We had experienced problems with JMerge when developing our data
>>>> model using EMF. So we decided to be independent from generated
>>>> code, separating hand-coded source folder from generated one.
>>> What kind of problems? We use it ourselves for the development of
>>> all our models and of course many other people use it as well, so any
>>> serious problems I would want to know about and fix.
>>>>
>>>> But we still needed services directly on top of the model.
>>>> So we introduced an EMF root class called ModelElement (extending
>>>> EObjectImpl to remain consistent).
>>>>
>>>> Moreover, we also experienced difficulties with auto-generated
>>>> element id when using provided xml persistence (with several files
>>>> on disk). So we introduced a ModelElementWithId top class in our
>>>> model (all others extending the latter), which provides EMF with an
>>>> "ID" tagged attribute (named id :)).
>>> What kind of problems did you have with auto-generated IDs? UML2
>>> uses them extensively and hit's used extensively in IBM's products...
>>>>
>>>> Eventually, we're having following structure : ModelElement
>>>> (hand-coded) <|---- ModelElementWithId (generated). EMF is
>>>> generating setId() and getId() methods automatically, which is
>>>> great. But also the quoted piece of code about id default value.
>>>>
>>>> But, to go on with our goal, generating an id is to be done in
>>>> ModelElement (since it's not subject to JMerge). So ModelElement is
>>>> providing with abstract method : public void setId(String ..)
>>>> (implemented here by ModelElementWithIdImpl) and a concrete method :
>>>> protected String generateId().
>>>>
>>>> And ModelElement constructor implementation does look like :
>>>> /**
>>>> * Constructor.
>>>> */
>>>> public ModelElement() {
>>>> // Set id at construction time.
>>>> setId(generateId());
>>>> ...
>>>> }
>>>>
>>> This seems like a bad idea because you will generate an ID during
>>> copying or when creating instances being deserialized and in those
>>> cases, that generated ID will quickly be overwritten by the
>>> copied/deserialized ID.
>>>> It seems to be the solution. But ModelElementWithIdImpl generated
>>>> code :
>>>> /**
>>>> * The default value of the '{@link #getId() Id}' attribute.
>>>> * 
>>>> * 
>>>> * @see #getId()
>>>> * @generated
>>>> * @ordered
>>>> */
>>>> protected static final String ID_EDEFAULT = null;
>>>>
>>>> /**
>>>> * The cached value of the '{@link #getId() Id}' attribute.
>>>> * 
>>>> * 
>>>> * @see #getId()
>>>> * @generated
>>>> * @ordered
>>>> */
>>>> protected String id = ID_EDEFAULT;
>>>>
>>>> /**
>>>> * 
>>>> * 
>>>> * @generated
>>>> */
>>>> protected ModelElementWithIdImpl() {
>>>> super();
>>>> }
>>>>
>>>> just erases our generated id with ID_EDEFAULT after exiting its
>>>> constructor (default value being executed at this time by java).
>>> I see. But as I said, I don't think generating an ID in the
>>> constructor is a good design approach. It would seem better to
>>> generate the ID on demand by overriding getID to return one rather
>>> than null.
>>>>
>>>> We used AspectJ to set the id after initialization of
>>>> ModelElementWithId. It worked as intended, but we are now facing a
>>>> new bug, that is so weird that we decide to get rid of AspectJ (for
>>>> testing purposes). And now we are unable to provide a generated
>>>> unique id for any model element, and be independent of generated
>>>> code at the same time.
>>>>
>>>> Removing ID_EDEFAULT from id declaration line just put things into
>>>> working state again, but that relies on JMerge capabilities (as
>>>> modifying ModelElementWithIdImpl constructor), which we vowed at
>>>> first not to use :).
>>> I really think modifying generated code should be fine and is
>>> certainly done by many many clients.
>>>>
>>>> And that's the end of the story, and I hope it helps understanding
>>>> my original question.
>>> In, 2.3.0, GenFeature has a hasEDefault method that's already used to
>>> guard the generation of the EDefaults, so perhaps we could add a
>>> persistent setting to GenFeature so that the value of hasEDefault can
>>> be explicitly turned off on a feature by feature basis. If you open
>>> a feature request, we'll consider that. The reason I thought you'd
>>> give for wanting this I had thought would be related to
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=147952; it actually has
>>> a performance impact to initialize to null rather than just leaving
>>> the field in the Java default state. But you current ID
>>> initialization approach has a much worse performance impact, so you
>>> should rethink it...
>>>>
>>>> Guillaume.
>>>>
>>>>
>>>>
>>>> Ed Merks wrote:
>>>>
>>>>> Guillaume,
>>>>
>>>>> No, there's no support for that, at least not yet. Given that the
>>>>> constructor can change the initial value, why does it make a huge
>>>>> difference to not have these "default" defaults?
>>>>
>>>>
>>>>> Guillaume wrote:
>>>>>> Hi,
>>>>>>
>>>>>> is there any way not to have a default value generated for an
>>>>>> attribute ?
>>>>>>
>>>>>> For instance, instead of generated code :
>>>>>> /**
>>>>>> * The default value of the '{@link #getId() Id}'
>>>>>> attribute.
>>>>>> * 
>>>>>> * 
>>>>>> * @see #getId()
>>>>>> * @generated
>>>>>> * @ordered
>>>>>> */
>>>>>> protected static final String ID_EDEFAULT = null;
>>>>>>
>>>>>> /**
>>>>>> * The cached value of the '{@link #getId() Id}' attribute.
>>>>>> * 
>>>>>> * 
>>>>>> * @see #getId()
>>>>>> * @generated
>>>>>> * @ordered
>>>>>> */
>>>>>> protected String id = ID_EDEFAULT;
>>>>>>
>>>>>> I would have liked a simple :
>>>>>> protected String id;
>>>>>>
>>>>>> Even if it does not seem different at first glance, it makes a
>>>>>> huge difference when using a custom root class for generated java
>>>>>> class, especially when trying to fill-up attributes in root class
>>>>>> constructor (using polymorphism on generated operations).
>>>>>>
>>>>>> Thanks in advance,
>>>>>> Guillaume.
>>>>>>
>>>>>>
>>>>
>>>>
>>

Report message to a moderator

Re: Attribute default value [message #407235 is a reply to message #407234]

Mon, 19 February 2007 11:33

Ed Merks
Messages: 24562
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------050806020006090503070506
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Guillaume,

The existing bug report will just change the templates to not generate
explicit assignments to a Java default value, e.g.,

protected EObject x = null;

will instead generate:

protected EObject x;

But that won't affect things that are generated as

protected String x = EDEFAULT_X;

So if you open a new bugzilla feature request, we'll look at providing
such support for this case. (Perhaps as a model level setting that says,
don't generate EDEFAULTs for features that don't have an explicit
default or as a per-feature setting.)

Guillaume wrote:
> Ed,
>
> comments below.
>
> Ed Merks wrote:
>
>> Guillaume,
>
>> I would personally find it very frustrating to have a repository that
>> contains code which is not complete (and cannot compile) until you
>> run a tool to generate the things needed to make it complete. We
>> certainly commit all our code to CVS and I'm pretty sure most clients
>> take that approach. I don't see how committing the code makes it
>> harder for anyone to generate a whole product; in fact, as I said, I
>> think it makes it easier by not forcing other users to generate the
>> whole product.
>
> Well that's something we could argue about.
> We have chosen the over approach (automated generation) (see martin
> fowler point of view in continuous integration).
> Moreover, part of the product is used as a generic framework, and
> requires users to get involved in the modeling process.
>
>> People have requested features for far thinner reasons. Since
>> generating an EDEFAULT that isn't needed has a performance cost, that
>> fact alone makes it reasonable to request a feature in order to
>> eliminate a cost when it's not needed. It's quite a trivial thing to
>> implement. I.e., I can imagine getting it done in far less than an
>> hour because mostly this involves adding an attribute to GenFeature,
>> generating the rest, and hooking hasEDefault to return false if this
>> new attribute is set to false...
>
> So what should I do ?
> Isn't the existing bug report enough ?
>
>> Guillaume wrote:
>>> Hi Ed,
>>>
>>> thanks for your answers.
>>> You are certainly right about the performance issue.
>>> Again, we used this approach so as to remain independent.
>>>
>>> I'll try overriding getId() directly. Still I'm not very found of
>>> this solution, for it forces us to have generated classes in version
>>> of control, and it makes it a bit harder for an external coder to
>>> generate the whole product. But it can be explained in an
>>> accompaning document.
>>>
>>> As for your bug request, I did not mention it (our model is not
>>> really big so far), but I do agree.
>>>
>>> Finally, for the feature request, I'll find it hard justifying it
>>> with our example (which is quite unsatisfying, and about to be
>>> changed accordingly to your comments).
>>>
>>> Again, thanks a lot for your swiftness.
>>>
>>> Guillaume
>>>
>>> PS : for merge issues, it was due to non-deletion of
>>> no-longer-designed classes (making it hard to sort out generated
>>> classes from no-longer ones). For id issues, I'll try to suppress
>>> the ID tag on id attribute, and see what happens.
>>>
>>>
>>> Ed Merks wrote:
>>>
>>>> Guillaume,
>>>
>>>> Comments below.
>>>
>>>
>>>> Guillaume wrote:
>>>>> Ed,
>>>>>
>>>>> I'll try to explain the situation as clearly as possible.
>>>>>
>>>>> We had experienced problems with JMerge when developing our data
>>>>> model using EMF. So we decided to be independent from generated
>>>>> code, separating hand-coded source folder from generated one.
>>>> What kind of problems? We use it ourselves for the development of
>>>> all our models and of course many other people use it as well, so
>>>> any serious problems I would want to know about and fix.
>>>>>
>>>>> But we still needed services directly on top of the model.
>>>>> So we introduced an EMF root class called ModelElement (extending
>>>>> EObjectImpl to remain consistent).
>>>>>
>>>>> Moreover, we also experienced difficulties with auto-generated
>>>>> element id when using provided xml persistence (with several files
>>>>> on disk). So we introduced a ModelElementWithId top class in our
>>>>> model (all others extending the latter), which provides EMF with
>>>>> an "ID" tagged attribute (named id :)).
>>>> What kind of problems did you have with auto-generated IDs? UML2
>>>> uses them extensively and hit's used extensively in IBM's products...
>>>>>
>>>>> Eventually, we're having following structure : ModelElement
>>>>> (hand-coded) <|---- ModelElementWithId (generated). EMF is
>>>>> generating setId() and getId() methods automatically, which is
>>>>> great. But also the quoted piece of code about id default value.
>>>>>
>>>>> But, to go on with our goal, generating an id is to be done in
>>>>> ModelElement (since it's not subject to JMerge). So ModelElement
>>>>> is providing with abstract method : public void setId(String ..)
>>>>> (implemented here by ModelElementWithIdImpl) and a concrete method
>>>>> : protected String generateId().
>>>>>
>>>>> And ModelElement constructor implementation does look like :
>>>>> /**
>>>>> * Constructor.
>>>>> */
>>>>> public ModelElement() {
>>>>> // Set id at construction time.
>>>>> setId(generateId());
>>>>> ...
>>>>> }
>>>>>
>>>> This seems like a bad idea because you will generate an ID during
>>>> copying or when creating instances being deserialized and in those
>>>> cases, that generated ID will quickly be overwritten by the
>>>> copied/deserialized ID.
>>>>> It seems to be the solution. But ModelElementWithIdImpl generated
>>>>> code :
>>>>> /**
>>>>> * The default value of the '{@link #getId() Id}'
>>>>> attribute.
>>>>> * 
>>>>> * 
>>>>> * @see #getId()
>>>>> * @generated
>>>>> * @ordered
>>>>> */
>>>>> protected static final String ID_EDEFAULT = null;
>>>>>
>>>>> /**
>>>>> * The cached value of the '{@link #getId() Id}' attribute.
>>>>> * 
>>>>> * 
>>>>> * @see #getId()
>>>>> * @generated
>>>>> * @ordered
>>>>> */
>>>>> protected String id = ID_EDEFAULT;
>>>>>
>>>>> /**
>>>>> * 
>>>>> * 
>>>>> * @generated
>>>>> */
>>>>> protected ModelElementWithIdImpl() {
>>>>> super();
>>>>> }
>>>>>
>>>>> just erases our generated id with ID_EDEFAULT after exiting its
>>>>> constructor (default value being executed at this time by java).
>>>> I see. But as I said, I don't think generating an ID in the
>>>> constructor is a good design approach. It would seem better to
>>>> generate the ID on demand by overriding getID to return one rather
>>>> than null.
>>>>>
>>>>> We used AspectJ to set the id after initialization of
>>>>> ModelElementWithId. It worked as intended, but we are now facing a
>>>>> new bug, that is so weird that we decide to get rid of AspectJ
>>>>> (for testing purposes). And now we are unable to provide a
>>>>> generated unique id for any model element, and be independent of
>>>>> generated code at the same time.
>>>>>
>>>>> Removing ID_EDEFAULT from id declaration line just put things into
>>>>> working state again, but that relies on JMerge capabilities (as
>>>>> modifying ModelElementWithIdImpl constructor), which we vowed at
>>>>> first not to use :).
>>>> I really think modifying generated code should be fine and is
>>>> certainly done by many many clients.
>>>>>
>>>>> And that's the end of the story, and I hope it helps understanding
>>>>> my original question.
>>>> In, 2.3.0, GenFeature has a hasEDefault method that's already used
>>>> to guard the generation of the EDefaults, so perhaps we could add
>>>> a persistent setting to GenFeature so that the value of hasEDefault
>>>> can be explicitly turned off on a feature by feature basis. If you
>>>> open a feature request, we'll consider that. The reason I thought
>>>> you'd give for wanting this I had thought would be related to
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=147952; it actually
>>>> has a performance impact to initialize to null rather than just
>>>> leaving the field in the Java default state. But you current ID
>>>> initialization approach has a much worse performance impact, so you
>>>> should rethink it...
>>>>>
>>>>> Guillaume.
>>>>>
>>>>>
>>>>>
>>>>> Ed Merks wrote:
>>>>>
>>>>>> Guillaume,
>>>>>
>>>>>> No, there's no support for that, at least not yet. Given that
>>>>>> the constructor can change the initial value, why does it make a
>>>>>> huge difference to not have these "default" defaults?
>>>>>
>>>>>
>>>>>> Guillaume wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> is there any way not to have a default value generated for an
>>>>>>> attribute ?
>>>>>>>
>>>>>>> For instance, instead of generated code :
>>>>>>> /**
>>>>>>> * The default value of the '{@link #getId() Id}'
>>>>>>> attribute.
>>>>>>> * 
>>>>>>> * 
>>>>>>> * @see #getId()
>>>>>>> * @generated
>>>>>>> * @ordered
>>>>>>> */
>>>>>>> protected static final String ID_EDEFAULT = null;
>>>>>>>
>>>>>>> /**
>>>>>>> * The cached value of the '{@link #getId() Id}'
>>>>>>> attribute.
>>>>>>> * 
>>>>>>> * 
>>>>>>> * @see #getId()
>>>>>>> * @generated
>>>>>>> * @ordered
>>>>>>> */
>>>>>>> protected String id = ID_EDEFAULT;
>>>>>>>
>>>>>>> I would have liked a simple :
>>>>>>> protected String id;
>>>>>>>
>>>>>>> Even if it does not seem different at first glance, it makes a
>>>>>>> huge difference when using a custom root class for generated
>>>>>>> java class, especially when trying to fill-up attributes in root
>>>>>>> class constructor (using polymorphism on generated operations).
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>> Guillaume.
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>

--------------050806020006090503070506
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Guillaume, 
 
The existing bug report will just change the templates to not generate
explicit assignments to a Java default value, e.g., 
<blockquote>protected EObject x = null; 
</blockquote>
will instead generate: 
<blockquote>protected EObject x; 
</blockquote>
But that won't affect things that are generated as 
<blockquote>protected String x = EDEFAULT_X; 
</blockquote>
So if you open a new bugzilla feature request, we'll look at providing
such support for this case. (Perhaps as a model level setting that
says, don't generate EDEFAULTs for features that don't have an explicit
default or as a per-feature setting.)

Report message to a moderator

Re: Attribute default value [message #407242 is a reply to message #407235]

Tue, 20 February 2007 02:07

Guillaume Brocard
Messages: 25
Registered: July 2009

Junior Member

Hi Ed,

Ok, I'll do this.
And thanks again for your answers.

Guillaume.

Ed Merks wrote:

> Guillaume,

> The existing bug report will just change the templates to not generate
> explicit assignments to a Java default value, e.g.,

> protected EObject x = null;

> will instead generate:

> protected EObject x;

> But that won't affect things that are generated as

> protected String x = EDEFAULT_X;

> So if you open a new bugzilla feature request, we'll look at providing
> such support for this case. (Perhaps as a model level setting that says,
> don't generate EDEFAULTs for features that don't have an explicit
> default or as a per-feature setting.)

> Guillaume wrote:
>> Ed,
>>
>> comments below.
>>
>> Ed Merks wrote:
>>
>>> Guillaume,
>>
>>> I would personally find it very frustrating to have a repository that
>>> contains code which is not complete (and cannot compile) until you
>>> run a tool to generate the things needed to make it complete. We
>>> certainly commit all our code to CVS and I'm pretty sure most clients
>>> take that approach. I don't see how committing the code makes it
>>> harder for anyone to generate a whole product; in fact, as I said, I
>>> think it makes it easier by not forcing other users to generate the
>>> whole product.
>>
>> Well that's something we could argue about.
>> We have chosen the over approach (automated generation) (see martin
>> fowler point of view in continuous integration).
>> Moreover, part of the product is used as a generic framework, and
>> requires users to get involved in the modeling process.
>>
>>> People have requested features for far thinner reasons. Since
>>> generating an EDEFAULT that isn't needed has a performance cost, that
>>> fact alone makes it reasonable to request a feature in order to
>>> eliminate a cost when it's not needed. It's quite a trivial thing to
>>> implement. I.e., I can imagine getting it done in far less than an
>>> hour because mostly this involves adding an attribute to GenFeature,
>>> generating the rest, and hooking hasEDefault to return false if this
>>> new attribute is set to false...
>>
>> So what should I do ?
>> Isn't the existing bug report enough ?
>>
>>> Guillaume wrote:
>>>> Hi Ed,
>>>>
>>>> thanks for your answers.
>>>> You are certainly right about the performance issue.
>>>> Again, we used this approach so as to remain independent.
>>>>
>>>> I'll try overriding getId() directly. Still I'm not very found of
>>>> this solution, for it forces us to have generated classes in version
>>>> of control, and it makes it a bit harder for an external coder to
>>>> generate the whole product. But it can be explained in an
>>>> accompaning document.
>>>>
>>>> As for your bug request, I did not mention it (our model is not
>>>> really big so far), but I do agree.
>>>>
>>>> Finally, for the feature request, I'll find it hard justifying it
>>>> with our example (which is quite unsatisfying, and about to be
>>>> changed accordingly to your comments).
>>>>
>>>> Again, thanks a lot for your swiftness.
>>>>
>>>> Guillaume
>>>>
>>>> PS : for merge issues, it was due to non-deletion of
>>>> no-longer-designed classes (making it hard to sort out generated
>>>> classes from no-longer ones). For id issues, I'll try to suppress
>>>> the ID tag on id attribute, and see what happens.
>>>>
>>>>
>>>> Ed Merks wrote:
>>>>
>>>>> Guillaume,
>>>>
>>>>> Comments below.
>>>>
>>>>
>>>>> Guillaume wrote:
>>>>>> Ed,
>>>>>>
>>>>>> I'll try to explain the situation as clearly as possible.
>>>>>>
>>>>>> We had experienced problems with JMerge when developing our data
>>>>>> model using EMF. So we decided to be independent from generated
>>>>>> code, separating hand-coded source folder from generated one.
>>>>> What kind of problems? We use it ourselves for the development of
>>>>> all our models and of course many other people use it as well, so
>>>>> any serious problems I would want to know about and fix.
>>>>>>
>>>>>> But we still needed services directly on top of the model.
>>>>>> So we introduced an EMF root class called ModelElement (extending
>>>>>> EObjectImpl to remain consistent).
>>>>>>
>>>>>> Moreover, we also experienced difficulties with auto-generated
>>>>>> element id when using provided xml persistence (with several files
>>>>>> on disk). So we introduced a ModelElementWithId top class in our
>>>>>> model (all others extending the latter), which provides EMF with
>>>>>> an "ID" tagged attribute (named id :)).
>>>>> What kind of problems did you have with auto-generated IDs? UML2
>>>>> uses them extensively and hit's used extensively in IBM's products...
>>>>>>
>>>>>> Eventually, we're having following structure : ModelElement
>>>>>> (hand-coded) <|---- ModelElementWithId (generated). EMF is
>>>>>> generating setId() and getId() methods automatically, which is
>>>>>> great. But also the quoted piece of code about id default value.
>>>>>>
>>>>>> But, to go on with our goal, generating an id is to be done in
>>>>>> ModelElement (since it's not subject to JMerge). So ModelElement
>>>>>> is providing with abstract method : public void setId(String ..)
>>>>>> (implemented here by ModelElementWithIdImpl) and a concrete method
>>>>>> : protected String generateId().
>>>>>>
>>>>>> And ModelElement constructor implementation does look like :
>>>>>> /**
>>>>>> * Constructor.
>>>>>> */
>>>>>> public ModelElement() {
>>>>>> // Set id at construction time.
>>>>>> setId(generateId());
>>>>>> ...
>>>>>> }
>>>>>>
>>>>> This seems like a bad idea because you will generate an ID during
>>>>> copying or when creating instances being deserialized and in those
>>>>> cases, that generated ID will quickly be overwritten by the
>>>>> copied/deserialized ID.
>>>>>> It seems to be the solution. But ModelElementWithIdImpl generated
>>>>>> code :
>>>>>> /**
>>>>>> * The default value of the '{@link #getId() Id}'
>>>>>> attribute.
>>>>>> * 
>>>>>> * 
>>>>>> * @see #getId()
>>>>>> * @generated
>>>>>> * @ordered
>>>>>> */
>>>>>> protected static final String ID_EDEFAULT = null;
>>>>>>
>>>>>> /**
>>>>>> * The cached value of the '{@link #getId() Id}' attribute.
>>>>>> * 
>>>>>> * 
>>>>>> * @see #getId()
>>>>>> * @generated
>>>>>> * @ordered
>>>>>> */
>>>>>> protected String id = ID_EDEFAULT;
>>>>>>
>>>>>> /**
>>>>>> * 
>>>>>> * 
>>>>>> * @generated
>>>>>> */
>>>>>> protected ModelElementWithIdImpl() {
>>>>>> super();
>>>>>> }
>>>>>>
>>>>>> just erases our generated id with ID_EDEFAULT after exiting its
>>>>>> constructor (default value being executed at this time by java).
>>>>> I see. But as I said, I don't think generating an ID in the
>>>>> constructor is a good design approach. It would seem better to
>>>>> generate the ID on demand by overriding getID to return one rather
>>>>> than null.
>>>>>>
>>>>>> We used AspectJ to set the id after initialization of
>>>>>> ModelElementWithId. It worked as intended, but we are now facing a
>>>>>> new bug, that is so weird that we decide to get rid of AspectJ
>>>>>> (for testing purposes). And now we are unable to provide a
>>>>>> generated unique id for any model element, and be independent of
>>>>>> generated code at the same time.
>>>>>>
>>>>>> Removing ID_EDEFAULT from id declaration line just put things into
>>>>>> working state again, but that relies on JMerge capabilities (as
>>>>>> modifying ModelElementWithIdImpl constructor), which we vowed at
>>>>>> first not to use :).
>>>>> I really think modifying generated code should be fine and is
>>>>> certainly done by many many clients.
>>>>>>
>>>>>> And that's the end of the story, and I hope it helps understanding
>>>>>> my original question.
>>>>> In, 2.3.0, GenFeature has a hasEDefault method that's already used
>>>>> to guard the generation of the EDefaults, so perhaps we could add
>>>>> a persistent setting to GenFeature so that the value of hasEDefault
>>>>> can be explicitly turned off on a feature by feature basis. If you
>>>>> open a feature request, we'll consider that. The reason I thought
>>>>> you'd give for wanting this I had thought would be related to
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=147952; it actually
>>>>> has a performance impact to initialize to null rather than just
>>>>> leaving the field in the Java default state. But you current ID
>>>>> initialization approach has a much worse performance impact, so you
>>>>> should rethink it...
>>>>>>
>>>>>> Guillaume.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ed Merks wrote:
>>>>>>
>>>>>>> Guillaume,
>>>>>>
>>>>>>> No, there's no support for that, at least not yet. Given that
>>>>>>> the constructor can change the initial value, why does it make a
>>>>>>> huge difference to not have these "default" defaults?
>>>>>>
>>>>>>
>>>>>>> Guillaume wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> is there any way not to have a default value generated for an
>>>>>>>> attribute ?
>>>>>>>>
>>>>>>>> For instance, instead of generated code :
>>>>>>>> /**
>>>>>>>> * The default value of the '{@link #getId() Id}'
>>>>>>>> attribute.
>>>>>>>> * 
>>>>>>>> * 
>>>>>>>> * @see #getId()
>>>>>>>> * @generated
>>>>>>>> * @ordered
>>>>>>>> */
>>>>>>>> protected static final String ID_EDEFAULT = null;
>>>>>>>>
>>>>>>>> /**
>>>>>>>> * The cached value of the '{@link #getId() Id}'
>>>>>>>> attribute.
>>>>>>>> * 
>>>>>>>> * 
>>>>>>>> * @see #getId()
>>>>>>>> * @generated
>>>>>>>> * @ordered
>>>>>>>> */
>>>>>>>> protected String id = ID_EDEFAULT;
>>>>>>>>
>>>>>>>> I would have liked a simple :
>>>>>>>> protected String id;
>>>>>>>>
>>>>>>>> Even if it does not seem different at first glance, it makes a
>>>>>>>> huge difference when using a custom root class for generated
>>>>>>>> java class, especially when trying to fill-up attributes in root
>>>>>>>> class constructor (using polymorphism on generated operations).
>>>>>>>>
>>>>>>>> Thanks in advance,
>>>>>>>> Guillaume.
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>

Report message to a moderator

Previous Topic:	refer to model classes from a jar file
Next Topic:	EMF 2.3.0M5 unsettable property

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat May 25 03:01:45 EDT 2013