Eclipse Community Forums: EMF » Influence generated method names for boolean attributes

Help

Home

Home » Modeling » EMF » Influence generated method names for boolean attributes

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

Influence generated method names for boolean attributes [message #870204]

Mon, 07 May 2012 05:13

Eclipse User

Hi EMF experts,
is it possible to influence the names of the generated getter method for
a boolean attribute? The default is, that a "is[AttributeName]" method
is generated. In my special case this method would better be named
"was[AttributeName]ed". Can I specify this anywhere without manually
simulating it by removing this attribute and adding two operations
(getter and setter) to the EClass.

best regards,
Gilbert

Report message to a moderator

Re: Influence generated method names for boolean attributes [message #870403 is a reply to message #870204]

Tue, 08 May 2012 00:23

Ed Merks
Messages: 24530
Registered: July 2009

Senior Member

Gilbert,

Comments below.

On 07/05/2012 11:13 AM, Gilbert Mirenque wrote:
> Hi EMF experts,
> is it possible to influence the names of the generated getter method for
> a boolean attribute? The default is, that a "is[AttributeName]" method
> is generated. In my special case this method would better be named
> "was[AttributeName]ed".
No, there's no way to influence anything beyond the name.
> Can I specify this anywhere without manually
> simulating it by removing this attribute and adding two operations
> (getter and setter) to the EClass.
No, and if you did that, they'd not be reflectively visible as
features. You might take the approach of suppressing the accessor's
visibility in the API (via annotations as produced by
EcoreUtil.setSuppressedVisibility) and defining operations in the API
that call the generated accessors in the implementation class.
>
> best regards,
> Gilbert

Report message to a moderator

Re: Influence generated method names for boolean attributes [message #870875 is a reply to message #870403]

Thu, 10 May 2012 02:57

Eclipse User

Hi Ed,

> No, and if you did that, they'd not be reflectively visible as
> features. You might take the approach of suppressing the accessor's
> visibility in the API (via annotations as produced by
> EcoreUtil.setSuppressedVisibility) and defining operations in the API
> that call the generated accessors in the implementation class.
Ok, that's an acceptable workaround. Thanks.

best regards,
Gilbert

Report message to a moderator

Previous Topic:	Limitation of EObjectContainmentEList
Next Topic:	Open SWT Dialog in ResourceSetListener.transactionAboutToCommit()

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sun May 19 19:48:09 EDT 2013