Home » Modeling » EMF » non-containment reference with eKeys()
| non-containment reference with eKeys() [message #415779] |
Sun, 06 January 2008 11:55  |
 Philipp W. Kutter
Messages: 301
Registered: July 2009 |
Senior Member |
|
|
Hi.
With a lot of help from Ed, I know now what
a containment reference does with eKeys():
it constructs references which use these
keys, rather than positions. This has the
advantage, that order in the tree does not
change the references.
Has anyone a use for eKeys() on non-containment references?
Best, Philipp
|
|
| |
| Re: non-containment reference with eKeys() [message #415790 is a reply to message #415782] |
Mon, 07 January 2008 06:59  |
Philipp W. Kutter
Messages: 301
Registered: July 2009 |
Senior Member |
|
|
I understand. The reference from A to B creates a constraint on B that
the combination of the eKeys() is unique within the resource.
In contrast, for containment-references, the uniqueness is only within
this contaiment, true?
It may be cool, if I could set eKeys() on a class, and then references
to that class would take these eKeys() as default value for their eKeys()
Similarly, if that feature would exist, eKeys() on the class could take
as default value the single ID feature, if existing. If an ID feature
would be a derived NCName-String from three features a,b,c, then the
eKeys() could express that these are the components of the "natural
key", as the non-technical key.
Clever people could then derive the implementation of a standard ID
feature from the info in the eKeys() of class.
Wondering what you think.
Best, Philipp
Ed Merks wrote:
> Philipp,
>
> It results in a constraint that's enforced by EObjectValidator.
> Imagine, for example, that we might define name as the key for
> eAllStructuralFeatures. And in the future we might generate a
> convenience lookup method perhaps based on an annotation that specifies
> the method name...
>
>
> Philipp W. Kutter wrote:
>> Hi.
>> With a lot of help from Ed, I know now what
>> a containment reference does with eKeys():
>> it constructs references which use these
>> keys, rather than positions. This has the
>> advantage, that order in the tree does not
>> change the references.
>>
>> Has anyone a use for eKeys() on non-containment references?
>>
>> Best, Philipp
|
|
|
| Re: non-containment reference with eKeys() [message #415791 is a reply to message #415790] |
Mon, 07 January 2008 07:20 |
Ed Merks
Messages: 24560
Registered: July 2009 |
Senior Member |
|
|
Philipp,
Comments below.
Philipp W. Kutter wrote:
> I understand. The reference from A to B creates a constraint on B that
> the combination of the eKeys() is unique within the resource.
It's a constraint that they are unique with respect to that particular
reference's set of referenced object. For a non-containment reference
the referenced objects could be in other resources (as for example of an
EClass' super types are in a different resource then the
eAllStructuralFeatures would also be spread across resources, but the
names must still be unique).
>
> In contrast, for containment-references, the uniqueness is only within
> this contaiment, true?
Given that even contained objects could be in a different resources,
there's really little difference.
>
> It may be cool, if I could set eKeys() on a class, and then references
> to that class would take these eKeys() as default value for their eKeys()
Yes, we thought about that. But it's more of a convenience and a quite
tricky to implement it automatically. I.e., what if I change the keys
of the class after the references already exist.
>
> Similarly, if that feature would exist, eKeys() on the class could
> take as default value the single ID feature, if existing. If an ID
> feature would be a derived NCName-String from three features a,b,c,
> then the eKeys() could express that these are the components of the
> "natural key", as the non-technical key.
It's more of an editing convenience though than anything else...
>
> Clever people could then derive the implementation of a standard ID
> feature from the info in the eKeys() of class.
>
> Wondering what you think.
I could see the two sets of information all too easily getting out of
sync...
>
> Best, Philipp
>
> Ed Merks wrote:
>> Philipp,
>>
>> It results in a constraint that's enforced by EObjectValidator.
>> Imagine, for example, that we might define name as the key for
>> eAllStructuralFeatures. And in the future we might generate a
>> convenience lookup method perhaps based on an annotation that
>> specifies the method name...
>>
>>
>> Philipp W. Kutter wrote:
>>> Hi.
>>> With a lot of help from Ed, I know now what
>>> a containment reference does with eKeys():
>>> it constructs references which use these
>>> keys, rather than positions. This has the
>>> advantage, that order in the tree does not
>>> change the references.
>>>
>>> Has anyone a use for eKeys() on non-containment references?
>>>
>>> Best, Philipp
|
|
|
Goto Forum:
Current Time: Fri May 24 16:29:44 EDT 2013
Powered by FUDForum. Page generated in 0.01590 seconds
|
] 
Search
Help
Register
Login
Home
