| Summary: | [evaluator] Sequence{1..1} has no iterable content | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] OCL | Reporter: | Ed Willink <ed> | ||||
| Component: | Core | Assignee: | OCL Inbox <mdt-ocl-inbox> | ||||
| Status: | CLOSED FIXED | QA Contact: | Ed Willink <ed> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | laurent.goubet | ||||
| Version: | 3.0.0 | Flags: | ed:
review?
(laurent.goubet) |
||||
| Target Milestone: | 3.0.2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows Vista | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 183324 [details]
Fix for singleton range
The problem is that on the first iteration of a singleton range hasNext does not find curr<last so it thinks it has finished.
An empty or negative range is not well-formed, so it seems sufficient to just return true for hasNext() in the starting !initialised context.
Ed,
Sequence{2..1} parses well into a CollectionRange, and such a range with your patch would allow for one iteration (as would Sequence{90..-50}). I think it would be better for the check to be
"return (curr < last) || (!initialized && curr == last);" so that we _only_ allow for this one iteration when the range has its "first" and "last" literals equal.
The OCL 2.2 specification is undecided about whether Sequence{2..1} is well-formed; the CollectionRangeEval::getRange recursion never terminates to yield a verdict. We can infer that since it counts up till it reaches last, that 2 is in range and 1 is not in range but all integers greater than 2 are also in range so Sequence{2..1} = Sequence{2,3,4,5,6,7,....}.
I've raised an OMG issue suggesting that it could be more useful to define Sequence{3..1} = Sequence{3,2,1}.
We could certainly implement this for 3.1; I'm not sure about 3.0.2 though.
Sequence{3..1} = Sequence{3,2,1} would be the best behavior, but as you mentionned, I don't think this should be done in 3.0.2. And indeed the behavior with your patch (Sequence{3..1} iterates once, on the integer "3") doesn't seem that wrong since the specification only gives examples counting "up".
+1 for the current patch.
Committed to HEAD and maintenance for 3.1.0M4 and 3.0.2. Closing all bugs resolved in Indigo. |
An attempt to iteration over Sequence{1..1} performs no iteration.