Eclipse Community Forums: EMF » "Class variable"-like behaviour in Ecore model

Help

Home

Home » Modeling » EMF » "Class variable"-like behaviour in Ecore model

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

"Class variable"-like behaviour in Ecore model [message #664288]

Fri, 08 April 2011 09:44

Martin Knauer

Messages: 10
Registered: July 2010
Location: Karlsruhe (DE) + Lyon (FR...

Junior Member

Hi,

as class variables i.e. static variables are not supported by Ecore for good reasons, I wonder if there's a pattern or best practice to model something close enough to this, i.e. references which are shared by all instances of the class in question.

I can think of a way to enforce this with an OCL constraint, but this would mean you still have to set the reference "manually" each time an instance is created. is there a better way?

Thanks in advance!

Report message to a moderator

Re: "Class variable"-like behaviour in Ecore model [message #664314 is a reply to message #664288]

Fri, 08 April 2011 11:02

Ed Willink

Messages: 6775
Registered: July 2009

Senior Member

Hi Martin

If you're using OCL then you can use OCL delegates to specify an initial
value or a derived value for a property; initialization happens
automatically.

OCL 2.2 introduced static properties but I don't think they'll help you,
even if they work. I've raised Bug 342263 to progress worries raised by
your use case.

Regards

Ed Willink

On 08/04/2011 10:44, Martin Knauer wrote:
> Hi,
>
> as class variables i.e. static variables are not supported by Ecore
> for good reasons, I wonder if there's a pattern or best practice to
> model something close enough to this, i.e. references which are shared
> by all instances of the class in question.
>
> I can think of a way to enforce this with an OCL constraint, but this
> would mean you still have to set the reference "manually" each time an
> instance is created. is there a better way?
>
> Thanks in advance!

Report message to a moderator

Re: "Class variable"-like behaviour in Ecore model [message #664353 is a reply to message #664288]

Fri, 08 April 2011 14:02

Ed Merks

Messages: 31280
Registered: July 2009

Senior Member

Martin,

Is this an issue about a default value for a single-valued
non-containment reference as Ed assumes, or more generally about sharing
read-only resources (containing shared constants)?

Martin Knauer wrote:
> Hi,
>
> as class variables i.e. static variables are not supported by Ecore
> for good reasons, I wonder if there's a pattern or best practice to
> model something close enough to this, i.e. references which are shared
> by all instances of the class in question.
>
> I can think of a way to enforce this with an OCL constraint, but this
> would mean you still have to set the reference "manually" each time an
> instance is created. is there a better way?
>
> Thanks in advance!

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: "Class variable"-like behaviour in Ecore model [message #664366 is a reply to message #664288]

Fri, 08 April 2011 14:58

Martin Knauer

Messages: 10
Registered: July 2010
Location: Karlsruhe (DE) + Lyon (FR...

Junior Member

Thanks a lot Ed & Ed for your replies!

Quote:

Is this an issue about a default value for a single-valued non-containment reference as Ed assumes, or more generally about sharing read-only resources (containing shared constants)?

In our specific case, it's about a non-containment reference which should be a list of the same values for every instance of the EClass. Default i.e. initial value is sufficient, but of course it would be a plus, if the lists were in sync. I will have a look into the OCL delegates indicated by Ed Willink.

Just in case, is there a reasonable non-OCL way to do this?

Report message to a moderator

Previous Topic:	Invalid entry feature exception from DelegatingFeatureMap.validate when switching to EStore
Next Topic:	model query

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Jul 16 05:15:10 GMT 2020

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter