Home » Modeling » EMF » Duplicate method set generated
| Duplicate method set generated [message #415716] |
Thu, 03 January 2008 10:37  |
|
Hello,
If I annotate my setter in my interfaces with @model the generated model
code contains duplicate methods. I assume this is a bug and if nobody
declines this, I will open a bug report.
Best regards, Lars
-------------
Example:
-----------------------------
package test;
/**
*
* @model
*/
public interface Testing {
/**
*
* @model
*/
public String getName();
/**
*
* @model
*/
public void setName(String value);
}
----------------------------
Create a new model based on this interface and create the model code from
it.
|
|
| |
| Re: Duplicate method set generated [message #415722 is a reply to message #415721] |
Thu, 03 January 2008 13:34  |
|
Hi Ed,
thank you. Bug: 214225. Best regards, Lars
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:flij7n$om2$1@build.eclipse.org...
> Lars,
>
> Sounds like a bug to me. I know the generator code will try to filter out
> such duplicate methods in the Impl but I think the generator code assumes
> the overload is generated by something from a base class rather than in
> the class itself. Of course putting @model on the set method seems kind
> of pointless. In any case, please open a bugzilla and we'll make sure it
> works.
>
>
> Lars Vogel wrote:
>> Hello,
>>
>> If I annotate my setter in my interfaces with @model the generated model
>> code contains duplicate methods. I assume this is a bug and if nobody
>> declines this, I will open a bug report.
>>
>> Best regards, Lars
>> -------------
>>
>> Example:
>> -----------------------------
>> package test;
>>
>> /**
>> *
>> * @model
>> */
>>
>> public interface Testing {
>>
>> /**
>> *
>> * @model
>> */
>>
>> public String getName();
>>
>> /**
>> *
>> * @model
>> */
>>
>> public void setName(String value);
>>
>> }
>> ----------------------------
>>
>> Create a new model based on this interface and create the model code from
>> it.
>>
>>
>>
>>
|
|
|
| Re: Duplicate method set generated [message #415736 is a reply to message #415722] |
Fri, 04 January 2008 15:59 |
 Philipp Kutter
Messages: 306
Registered: July 2009 |
Senior Member |
|
|
Hi, everybody.
My understanding would be that the @model tag on the setter tells EMF
that there is an operation.
If the getter has an @model tag, and not the tag telling that this is an
operation, the getter tells EMF that there is a feature, and if the
feature is changeable=true, then there is duplicate code.
Thus what is needed would be, that the "Y getX()" and "setX(Y v)"
operations are identified as conflicting with the X feature of type Y
and it would mark this ECore model as illegal.
In my opinion we should be careful not to rule out configurations which
do not lead to correct code. For instance, it may make a lot of sense,
to add operations Z getX() and setX(Z) where Z is a subtype of Y.
Does this make sense?
Best, Philipp
PS
Personally, I'd love to be able to allow a feature X of type Y in a
class, and then to allow a feature of type Z->Y in the subclass, but
we discussed this in extenso. There the workaround is an operation
Y getX() in the superclass, and feature X of type Z in the subclass.
Lars Vogel wrote:
> Hi Ed,
>
> thank you. Bug: 214225. Best regards, Lars
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:flij7n$om2$1@build.eclipse.org...
>> Lars,
>>
>> Sounds like a bug to me. I know the generator code will try to filter out
>> such duplicate methods in the Impl but I think the generator code assumes
>> the overload is generated by something from a base class rather than in
>> the class itself. Of course putting @model on the set method seems kind
>> of pointless. In any case, please open a bugzilla and we'll make sure it
>> works.
>>
>>
>> Lars Vogel wrote:
>>> Hello,
>>>
>>> If I annotate my setter in my interfaces with @model the generated model
>>> code contains duplicate methods. I assume this is a bug and if nobody
>>> declines this, I will open a bug report.
>>>
>>> Best regards, Lars
>>> -------------
>>>
>>> Example:
>>> -----------------------------
>>> package test;
>>>
>>> /**
>>> *
>>> * @model
>>> */
>>>
>>> public interface Testing {
>>>
>>> /**
>>> *
>>> * @model
>>> */
>>>
>>> public String getName();
>>>
>>> /**
>>> *
>>> * @model
>>> */
>>>
>>> public void setName(String value);
>>>
>>> }
>>> ----------------------------
>>>
>>> Create a new model based on this interface and create the model code from
>>> it.
>>>
>>>
>>>
>>>
>
>
|
|
|
| Re: Duplicate method set generated [message #415747 is a reply to message #415736] |
Fri, 04 January 2008 19:15 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Philipp,
I'd suggest comments in the bugzilla. Others are advocating threating
this (an EClass has a local operation that collides with a local
feature's accessor) as an error and at this point, that's the way it
will go unless others argue convincingly to the contrary.
Philipp W. Kutter wrote:
> Hi, everybody.
> My understanding would be that the @model tag on the setter tells EMF
> that there is an operation.
>
> If the getter has an @model tag, and not the tag telling that this is
> an operation, the getter tells EMF that there is a feature, and if the
> feature is changeable=true, then there is duplicate code.
>
> Thus what is needed would be, that the "Y getX()" and "setX(Y v)"
> operations are identified as conflicting with the X feature of type Y
> and it would mark this ECore model as illegal.
>
> In my opinion we should be careful not to rule out configurations
> which do not lead to correct code. For instance, it may make a lot of
> sense,
> to add operations Z getX() and setX(Z) where Z is a subtype of Y.
>
> Does this make sense?
>
> Best, Philipp
>
> PS
> Personally, I'd love to be able to allow a feature X of type Y in a
> class, and then to allow a feature of type Z->Y in the subclass, but
> we discussed this in extenso. There the workaround is an operation
> Y getX() in the superclass, and feature X of type Z in the subclass.
>
>
>
>
> Lars Vogel wrote:
>> Hi Ed,
>>
>> thank you. Bug: 214225. Best regards, Lars
>>
>> "Ed Merks" <merks@ca.ibm.com> wrote in message
>> news:flij7n$om2$1@build.eclipse.org...
>>> Lars,
>>>
>>> Sounds like a bug to me. I know the generator code will try to
>>> filter out such duplicate methods in the Impl but I think the
>>> generator code assumes the overload is generated by something from a
>>> base class rather than in the class itself. Of course putting
>>> @model on the set method seems kind of pointless. In any case,
>>> please open a bugzilla and we'll make sure it works.
>>>
>>>
>>> Lars Vogel wrote:
>>>> Hello,
>>>>
>>>> If I annotate my setter in my interfaces with @model the generated
>>>> model code contains duplicate methods. I assume this is a bug and
>>>> if nobody declines this, I will open a bug report.
>>>>
>>>> Best regards, Lars
>>>> -------------
>>>>
>>>> Example:
>>>> -----------------------------
>>>> package test;
>>>>
>>>> /**
>>>> *
>>>> * @model
>>>> */
>>>>
>>>> public interface Testing {
>>>>
>>>> /**
>>>> *
>>>> * @model
>>>> */
>>>>
>>>> public String getName();
>>>>
>>>> /**
>>>> *
>>>> * @model
>>>> */
>>>>
>>>> public void setName(String value);
>>>>
>>>> }
>>>> ----------------------------
>>>>
>>>> Create a new model based on this interface and create the model
>>>> code from it.
>>>>
>>>>
>>>>
>>>>
>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Duplicate method set generated [message #415762 is a reply to message #415747] |
Fri, 04 January 2008 21:44 |
Philipp Kutter
Messages: 306
Registered: July 2009 |
Senior Member |
|
|
Done. Thanks for the hint. All our nice covariance examples and what you
told about interfaces which should rather have getter and setter as
operations would not work anymore.
Best, Philipp
Ed Merks wrote:
> Philipp,
>
> I'd suggest comments in the bugzilla. Others are advocating threating
> this (an EClass has a local operation that collides with a local
> feature's accessor) as an error and at this point, that's the way it
> will go unless others argue convincingly to the contrary.
>
>
> Philipp W. Kutter wrote:
>> Hi, everybody.
>> My understanding would be that the @model tag on the setter tells EMF
>> that there is an operation.
>>
>> If the getter has an @model tag, and not the tag telling that this is
>> an operation, the getter tells EMF that there is a feature, and if the
>> feature is changeable=true, then there is duplicate code.
>>
>> Thus what is needed would be, that the "Y getX()" and "setX(Y v)"
>> operations are identified as conflicting with the X feature of type Y
>> and it would mark this ECore model as illegal.
>>
>> In my opinion we should be careful not to rule out configurations
>> which do not lead to correct code. For instance, it may make a lot of
>> sense,
>> to add operations Z getX() and setX(Z) where Z is a subtype of Y.
>>
>> Does this make sense?
>>
>> Best, Philipp
>>
>> PS
>> Personally, I'd love to be able to allow a feature X of type Y in a
>> class, and then to allow a feature of type Z->Y in the subclass, but
>> we discussed this in extenso. There the workaround is an operation
>> Y getX() in the superclass, and feature X of type Z in the subclass.
>>
>>
>>
>>
>> Lars Vogel wrote:
>>> Hi Ed,
>>>
>>> thank you. Bug: 214225. Best regards, Lars
>>>
>>> "Ed Merks" <merks@ca.ibm.com> wrote in message
>>> news:flij7n$om2$1@build.eclipse.org...
>>>> Lars,
>>>>
>>>> Sounds like a bug to me. I know the generator code will try to
>>>> filter out such duplicate methods in the Impl but I think the
>>>> generator code assumes the overload is generated by something from a
>>>> base class rather than in the class itself. Of course putting
>>>> @model on the set method seems kind of pointless. In any case,
>>>> please open a bugzilla and we'll make sure it works.
>>>>
>>>>
>>>> Lars Vogel wrote:
>>>>> Hello,
>>>>>
>>>>> If I annotate my setter in my interfaces with @model the generated
>>>>> model code contains duplicate methods. I assume this is a bug and
>>>>> if nobody declines this, I will open a bug report.
>>>>>
>>>>> Best regards, Lars
>>>>> -------------
>>>>>
>>>>> Example:
>>>>> -----------------------------
>>>>> package test;
>>>>>
>>>>> /**
>>>>> *
>>>>> * @model
>>>>> */
>>>>>
>>>>> public interface Testing {
>>>>>
>>>>> /**
>>>>> *
>>>>> * @model
>>>>> */
>>>>>
>>>>> public String getName();
>>>>>
>>>>> /**
>>>>> *
>>>>> * @model
>>>>> */
>>>>>
>>>>> public void setName(String value);
>>>>>
>>>>> }
>>>>> ----------------------------
>>>>>
>>>>> Create a new model based on this interface and create the model
>>>>> code from it.
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 03:35:21 GMT 2024
Powered by FUDForum. Page generated in 0.03238 seconds |
] 
Search
Help
Register
Login
Home
