|
|
| Re: EMap implemention does not support inverse reference of contained entries [message #484073 is a reply to message #484011] |
Fri, 04 September 2009 08:35   |
 Mario Winterer
Messages: 136
Registered: July 2009 |
Senior Member |
|
|
Ed Merks schrieb:
> Mario,
>
> Comments below.
>
> Mario Winterer wrote:
>> Hi!
>>
>> It seems that the default EMap-implementation does not support map
>> entry objects that have a (navigatable) inverse reference to their
>> container.
>>
>> Let's take an example model of a spreadsheet application.
>> We've a class Row that holds a list of Column-to-Cell map entries.
>>
>> Row
>> + cells: ColumnToCellMapEntry (0..*) [containment]
>>
>> ColumnToCellMapEntry
>> + key: Column
>> + value: Cell [containment]
>> + row: Row [opposite of Row.cells]
>>
>>
>> Having the generated java code, the following code snippet fails
>> (assuming, row, column and cell are three valid instances of their
>> namesake-types):
>>
>> row.getCells().put(column, cell);
>> ColumnToCellMapEntryImpl entry = (Column...EntryImpl)cell.eContainer();
>> assert row == entry.getRow(); // fails!
>>
>>
>> getRow will always return null as the internal EList used by EMap is
>> not aware of the navigatable inverse reference.
>>
>>
>> Is that a bug?
> A limitation. There isn't even a generated API for the map entry itself
> and client code should not be using Impl classes so they should only be
> using the Map.Entry API.
OK. It isn't a really limiting limitation, but I hoped I could use it
model-internally for convenience to implement other operations.
By the way: Adding a map entry using commands is surprisingly hard as
the "public" Map.Entry API does not offer a setter for the key. So it is
necessary to either cast to SomethingToSomethingMapEntryImpl (which is
internal API), or to BasicEMap.Entry, which means we've to assume that
the (internal) map implementation is a BasicEMap...
>>
>> Thanks,
>> Mario
|
|
|
| Re: EMap implemention does not support inverse reference of contained entries [message #484206 is a reply to message #484073] |
Fri, 04 September 2009 15:02 |
Ed Merks
Messages: 33217
Registered: July 2009 |
Senior Member |
|
|
Mario,
Comments below.
Mario Winterer wrote:
> Ed Merks schrieb:
>> Mario,
>>
>> Comments below.
>>
>> Mario Winterer wrote:
>>> Hi!
>>>
>>> It seems that the default EMap-implementation does not support map
>>> entry objects that have a (navigatable) inverse reference to their
>>> container.
>>>
>>> Let's take an example model of a spreadsheet application.
>>> We've a class Row that holds a list of Column-to-Cell map entries.
>>>
>>> Row
>>> + cells: ColumnToCellMapEntry (0..*) [containment]
>>>
>>> ColumnToCellMapEntry
>>> + key: Column
>>> + value: Cell [containment]
>>> + row: Row [opposite of Row.cells]
>>>
>>>
>>> Having the generated java code, the following code snippet fails
>>> (assuming, row, column and cell are three valid instances of their
>>> namesake-types):
>>>
>>> row.getCells().put(column, cell);
>>> ColumnToCellMapEntryImpl entry = (Column...EntryImpl)cell.eContainer();
>>> assert row == entry.getRow(); // fails!
>>>
>>>
>>> getRow will always return null as the internal EList used by EMap is
>>> not aware of the navigatable inverse reference.
>>>
>>>
>>> Is that a bug?
>> A limitation. There isn't even a generated API for the map entry
>> itself and client code should not be using Impl classes so they
>> should only be using the Map.Entry API.
>
> OK. It isn't a really limiting limitation, but I hoped I could use it
> model-internally for convenience to implement other operations.
In the end, it's just going to call eContainer and cast the result, so
you could do that instead too.
>
> By the way: Adding a map entry using commands is surprisingly hard as
> the "public" Map.Entry API does not offer a setter for the key.
It doesn't really make sense to set the key. Have a look at how
BasicEMap.put does it's job. I.e., you either set the value of an
existing entry with a matching key or you create a new entry.
> So it is necessary to either cast to SomethingToSomethingMapEntryImpl
> (which is internal API), or to BasicEMap.Entry, which means we've to
> assume that the (internal) map implementation is a BasicEMap...
Actually it's possible to use EMF reflection as well. Assuming
BasicEMap.Entry is implemented by the entry is a safe assumption (just
like assuming that an EObject also implements InternalEObject).
>
>>>
>>> Thanks,
>>> Mario
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.10109 seconds
] 
Search
Help
Register
Login
Home
