Eclipse Community Forums: OCL » Map type support in OCL?

Help

Home

Home » Modeling » OCL » Map type support in OCL?(OCL language support for Map)

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

Map type support in OCL? [message #1797870]

Wed, 07 November 2018 16:57

Kevin Lano

Messages: 1
Registered: November 2018

Junior Member

Is there an intention to add a Map type to OCL for the next OMG version or in Eclipse?
This would be very useful for developing software tools in OCL.

I have been using a partial implementation (similar to ATL's Map) for some time, here
are details of this & a Python library for it.

Attachment: ocl.py
(Size: 7.76KB, Downloaded 104 times)
Attachment: oclmap.pdf
(Size: 32.46KB, Downloaded 117 times)

Report message to a moderator

Re: Map type support in OCL? [message #1797925 is a reply to message #1797870]

Thu, 08 November 2018 15:41

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Kevin

Thank you for reposting your private communication.

[1] (Basic Map) identifies the addition of a prototype Map type to the Pivot-based Eclipse OCL over three years ago following discussion at OCL 2014. See the model at [4]

[2] (Map construction) was raised two weeks ago when it become clear that constructing a Map could be really tedious/inefficient.

[3] (Map iteration) was raised yesterday in response to your private communication preceding this forum posting.

I have done a little coding yesterday and today to see how iterators might work out.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=462721
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=540353
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=540884
[4] http://git.eclipse.org/c/ocl/org.eclipse.ocl.git/tree/plugins/org.eclipse.ocl.pivot/model/OCL-2.5.oclstdlib

---

The Eclipse OCL prototype Map was inspired by ATL and discussion with Frederic Jouault. Names, such as "at" rather than "get", were revised to be consistent with side effect free OCL rather than imperative Java. There is therefore considerable commonality with your ideas. Perhaps a notable difference is that Map.at returns invalid just like Sequence.at for index-out-of-bounds, which is consistent and necessary since keys and/or values may be null.

Despite comments from many authors, including myself, that a Set of Tuple can be a Map. It cannot. Uniqueness is on the key not the tuple. Consequently an asSet() implementation is dangerous.

Consistency is pushing me towards collectNestedBy for the simple key to f(key) Map constructor and collectBy for the key to flattened(f(key)) MultiMap constructor. I'm not happy with the 'spelling'.

"inverse" is certainly interesting.

"count" probably needs to be the rather degenerate key by default and "countValue"

Feel free to add comments to the Bugzillas.

Regards

Ed Willink

Report message to a moderator