Bugzilla – Full Text Bug Listing
| Summary: | [library] Set operations like including(obj) and excluding(obj) should be specialized for OrederedSet | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] OCL | Reporter: | Sergey Boyko <serg.boyko2011> | ||||
| Component: | Core | Assignee: | OCL Inbox <mdt-ocl-inbox> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | alexander.igdalov, ed | ||||
| Version: | 1.2.0 | Keywords: | plan | ||||
| Target Milestone: | 3.1.0 | Flags: | ed:
indigo+
|
||||
| Hardware: | PC | ||||||
| OS: | Windows Vista | ||||||
| Whiteboard: | Compliance | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 156363 | ||||||
| Attachments: |
|
||||||
|
Description
Sergey Boyko
Same notes for Collection.product() operation. I believe that in case when both operand and parameter are 'oredered' (that are Sequence and OrederedSet) product() should result in OrederedSet instead of plain Set type. Hi, Sergey, My first reaction was to resolve this as NOT_ECLIPSE because the problem, if there is one, is in the OCL specification and would more appropriately be raised as an issue to the OMG. However, MDT OCL has a history of deviation from the spec (more recently with user options for validation), so there may be some wiggle room, but I don't think there is much because this would have to add operations to the standard library. Is this important to QVTo in some way? I imagine that the QVT language would be bound by the OCL language's limitations in this regard. There are recent developments in this area in the OCL 2.1 RTF. The 1st ballot of resolutions is now open, and it includes (among many others) the following changes:
- clarification that OrderedSet(T) is *not* a subtype of Set(T)
- definition of the iterators and asSet()/asSequence()/etc.
coercion operations for OrderedSet(T)
I'm not sure that this will solve your problem because the including() operation and, more importantly, excluding() still won't be defined. I'll raise an issue for that with OMG and propose a resolution for the next ballot. There should be time for another ballot, as the 2.1 report is now postponed to the March 2009 meeting.
Rather than open up the stdlib in this release, I'd like to wait until 2.0, which should be the next after Galileo in which I assume that we'll be able to adopt the 2.1 spec, which has numerous incompatible changes (that are nonetheless significant improvements).
Christian, thanks a lot for your effort with OCL RTF and ballots. Actually that request comes from our field users that claims about unpredictable transformation results when forgetting (at least once :) to explicitly call asSequence() before including/excluding operations. Of course it can be postponed till 2.0. Created attachment 140911 [details]
Proposed patch
That patch may be applied without adding OrderedSet::including() and OrderedSet::excluding() specializations to stdlib. In other words only internal handling of these operations may be provided.
However it looks more convenient to provide correct specializations as well.
Thanks Sergey. That gives us a clear example of where we need 2.0/2.2 behavioural variation. CollectionUtil.java needs 2.0/2.2 behavioural variation. OCLStandardLibraryUtil.java needs 2.0/2.2 behavioural variation. CollectionsTest.java must test each behaviour. I'm currently refactoring to make test code Ecore/UML neutral. Launch configurations are probably affected only by regeneration rather than any genuine change. -- oclstdlib.uml and oclstdlib.ecore perhaps need saving as perhaps oclstdlib2_0.uml and oclstdlib2_0.ecore before the upgrade. 2.0/2.2 Behavioural selection must select. Maintaining multiple copies of oclstdlib.uml/ecore is not scaleable to arbitrary derived languages. I suggest that we provide an OCLUtil.generateOCLStdLib method that takes the primary oclstdlib, performs the relevant edits, and emits a changed Resource that can be saved under a user selectable name. This will support any combination of behavioural changes. We can provide a JUnit test to validate that the distributed oclstdlib2_0 from CVS is the same as that resulting from applying 2.0 behavioural edits to oclstdlib. This bug drew my attention to the following problem. The new spec draft as of 09-05-02 clearly states in 11.6.3 that OrderedSet is not a subtype of Set. Therefore, Set operations such as union, intersection, including and excluding that have been defined on OrderedSet in the previous implementation should be removed from the standard library. As another consequence, this patch should be applied either. This is a very important change which might be inconvenient for OCL clients. I suppose we should address this issue to OMG. (In reply to comment #7) > As another consequence, this patch should be applied either. I meant "As another consequence, this patch shouldn't be applied either" The new librarty model introduces OrderedCollection to share OrderedSet and Sequence operations. Resolved for Indigo is 3.1.0 not 3.2.0. Closing all bugs resolved in Indigo. |