| Containment/Container/EOpposite with inherited references [message #427924] |
Fri, 06 March 2009 03:04  |
Eclipse User |
|
|
|
Hello newsgroup,
it looks like I've got myself stuck with a modeling issue here. I've got
the following situation, in pseudo-code:
abstract class AbstractObject:
container: container reference[1] to ObjectContainer
class ObjectTypeA extends AbstractObject:
some specific properties
class ObjectTypeB extends AbstractObject:
some other properties
class ObjectContainer:
containedAs: containment reference[0..*] to ObjectTypeA
containedBs: containment reference[0..*] to ObjectTypeB
At least this is what I want - every subclass of AbstractObject must be
contained in an ObjectContainer and should have a common method for
accessing the container. I can't seem to get this right in the Ecore
file - as soon as I set the EOpposite property of containedBs to
container, the property container of AbstractObjects points to
containedBs as its reference. Right now, the only way I can think of is
copy the container property into every subclass and declare an abstract
method getContainer() in the AbstractObject. Is there a better way to do
this?
Thanks
Volker
--
* Volker Wegert * http://www.volker-wegert.de/contact *
"Die Welt ist nichts als ein großes Gefängnis, aus dem jeden Tag einige zur
Exekution geführt werden." (Sir Walter Raleigh)
|
|
|
|
| Re: Containment/Container/EOpposite with inherited references [message #427938 is a reply to message #427934] |
Fri, 06 March 2009 06:42  |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------010200030506030905050903
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Guys,
Comments below.
Jose Hernandez wrote:
> Volker,
>
> You could redefined ObjectContainer like this:
>
> class ObjectContainer:
> containedObjects: containment reference[0..*] to AbstractObject
>
Yes, the point being that the opposite of the opposite must be the
original feature. So it follows that you cannot have a single container
reference that's shared by multiple containment references.
It's also possible to define the container reference as unchangeable,
transient, volatile, derived and then implement it to return
eContainer() if the eContainer() is an ObjectContainer instance. Or
make it an EOperation for that matter...
> and then use a feature map or a method in ObjectContainer that return an
> elist of objects of either A or B.
> e.g. EList getContainedObjects(EClass target class)
>
> Regards
> Jose
>
> "Volker Wegert" <mail@volker-wegert.de> wrote in message
> news:m2k573dqm8.fsf@gideon.home.volker-wegert.de...
>
>> Hello newsgroup,
>>
>> it looks like I've got myself stuck with a modeling issue here. I've got
>> the following situation, in pseudo-code:
>>
>> abstract class AbstractObject:
>> container: container reference[1] to ObjectContainer
>>
>> class ObjectTypeA extends AbstractObject:
>> some specific properties
>>
>> class ObjectTypeB extends AbstractObject:
>> some other properties
>>
>> class ObjectContainer:
>> containedAs: containment reference[0..*] to ObjectTypeA
>> containedBs: containment reference[0..*] to ObjectTypeB
>>
>> At least this is what I want - every subclass of AbstractObject must be
>> contained in an ObjectContainer and should have a common method for
>> accessing the container. I can't seem to get this right in the Ecore
>> file - as soon as I set the EOpposite property of containedBs to
>> container, the property container of AbstractObjects points to
>> containedBs as its reference. Right now, the only way I can think of is
>> copy the container property into every subclass and declare an abstract
>> method getContainer() in the AbstractObject. Is there a better way to do
>> this?
>>
>> Thanks
>> Volker
>>
>> --
>> * Volker Wegert * http://www.volker-wegert.de/contact *
>> "Die Welt ist nichts als ein gro
|
|
|
|
|
| Re: Containment/Container/EOpposite with inherited references [message #427981 is a reply to message #427978] |
Mon, 09 March 2009 08:12 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------080407060502030405030105
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Volker,
Given that map entries don't generate an API but only an implementation
class, the value of a container feature seems to be quite limited. We'd
need more flavors of DelegateEObjectContainmentEList (a WithInverse
flavor). It's not a totally unreasonable to desire that though...
Volker Wegert wrote:
> Ed Merks <Ed.Merks@gmail.com> writes:
>
>> Yes, the point being that the opposite of the opposite must be the original
>> feature. So it follows that you cannot have a single container reference
>> that's shared by multiple containment references.
>>
>
> Ed, this is disappointing. You're really breaking the EMF-is-omnipotent
> and Ed-reads-your-mind illusions here. ;-)
>
It's kind of a EMOF/CMOF/UML limitation even...
> That being said, it's too bad that I can't define an opposite when
> using a map (a containment reference to a map entry whose value is again
> a containment reference) - are there any plans to support this?
>
Not yet...
>
>> It's also possible to define the container reference as unchangeable,
>> transient, volatile, derived and then implement it to return eContainer() if
>> the eContainer() is an ObjectContainer instance.
>>
>
> This is an interesting approach - I'll evaluate this. Certainly cleaner
> than what I did...
>
> Thanks
> Volker
>
>
--------------080407060502030405030105
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Volker,<br>
<br>
Given that map entries don't generate an API but only an implementation
class, the value of a container feature seems to be quite limited.
We'd need more flavors of DelegateEObjectContainmentEList (a
WithInverse flavor). It's not a totally unreasonable to desire that
though...<br>
<br>
<br>
Volker Wegert wrote:
<blockquote cite="mid:m263ijzmmf.fsf@gideon.home.volker-wegert.de"
type="cite">
<pre wrap="">Ed Merks <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com"><Ed.Merks@gmail.com></a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">Yes, the point being that the opposite of the opposite must be the original
feature. So it follows that you cannot have a single container reference
that's shared by multiple containment references.
</pre>
</blockquote>
<pre wrap=""><!---->
Ed, this is disappointing. You're really breaking the EMF-is-omnipotent
and Ed-reads-your-mind illusions here. ;-)
</pre>
</blockquote>
It's kind of a EMOF/CMOF/UML limitation even...<br>
<blockquote cite="mid:m263ijzmmf.fsf@gideon.home.volker-wegert.de"
type="cite">
<pre wrap="">
That being said, it's too bad that I can't define an opposite when
using a map (a containment reference to a map entry whose value is again
a containment reference) - are there any plans to support this?
</pre>
</blockquote>
Not yet...<br>
<blockquote cite="mid:m263ijzmmf.fsf@gideon.home.volker-wegert.de"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">It's also possible to define the container reference as unchangeable,
transient, volatile, derived and then implement it to return eContainer() if
the eContainer() is an ObjectContainer instance.
</pre>
</blockquote>
<pre wrap=""><!---->
This is an interesting approach - I'll evaluate this. Certainly cleaner
than what I did...
Thanks
Volker
</pre>
</blockquote>
</body>
</html>
--------------080407060502030405030105--
|
|
|
Powered by
FUDForum. Page generated in 0.25786 seconds
Home