Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Sequence.subSequence with invalid arguments
Sequence.subSequence with invalid arguments [message #60961] Wed, 20 August 2008 16:18 Go to next message
Eclipse User
Originally posted by: artem.borland.com

Hello,

Sequence{'single-element'}->subSequence(2, 1) evaluates to null, not
invalid as one might expect. Null, as a legal value, might get mixed with
other values being collected along with the incorrect subSequence
expression, and tracing such problem might be quite tricky. I wonder if
OCL spec mandates null for such cases (I didn't find anything, however)
or if there's reason to have null.

As a side note, it looks odd to me one can't use subSequence to end up
with empty collection. Is there any design rationale behind that as well?
Re: Sequence.subSequence with invalid arguments [message #60985 is a reply to message #60961] Wed, 20 August 2008 17:01 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Hi, Artem,

I would expect invalid in the case of subSequence(2, 1) because that
violates a pre-condition constraint of the Sequence::subsequence()
operation. Please raise a bug for this.

Yes, it is odd that one cannot take an empty sub-sequence. That's a
consequence of the upper bound being inclusive, which was a deliberate
decision in the language design. I don't know that the consequence of
being unable to specify an empty range was intended, though. Certainly,
it couldn't be fixed by allowing a lower bound one greater than the
upper bound, which would just be two wrongs making something ugly (not
at all right).

OCL has the empty-sequence literal for these cases; I guess that'll have
to do.

Cheers,

Christian

Artem Tikhomirov wrote:
> Hello,
>
> Sequence{'single-element'}->subSequence(2, 1) evaluates to null, not
> invalid as one might expect. Null, as a legal value, might get mixed
> with other values being collected along with the incorrect subSequence
> expression, and tracing such problem might be quite tricky. I wonder if
> OCL spec mandates null for such cases (I didn't find anything, however)
> or if there's reason to have null.
>
> As a side note, it looks odd to me one can't use subSequence to end up
> with empty collection. Is there any design rationale behind that as well?
>
Re: Sequence.subSequence with invalid arguments [message #61053 is a reply to message #60985] Wed, 20 August 2008 18:45 Go to previous messageGo to next message
Radomil Dvorak is currently offline Radomil Dvorak
Messages: 249
Registered: July 2009
Senior Member
Hi Christian,

It seems that subSequence(...) is not the only case where invalid would =
be =

a more
appropriate return value.
For instance, Sequence::at(Integer) operation if called with an index ou=
t =

of bounds
should give invalid rather then null IMO.
If not, it might appear that null element exists at that position.

Consequently, first(), last() operations seem affected too as
Sequence{}->first() =3D Sequence{}->including(null)->first()
might confuse things a bit.

However, the OMG spec says, "->first() element of an empty collection wi=
ll =

result in undefined.",
though in a bit strange place for this operation contract ;).

I can surely raise a bugzilla if you agree it's something to be fixed.

Regards,
/Radek


On Wed, 20 Aug 2008 23:01:48 +0200, Christian W. Damus =

<cdamus@zeligsoft.com> wrote:

> Hi, Artem,
>
> I would expect invalid in the case of subSequence(2, 1) because that =

> violates a pre-condition constraint of the Sequence::subsequence() =

> operation. Please raise a bug for this.
>
> Yes, it is odd that one cannot take an empty sub-sequence. That's a =

> consequence of the upper bound being inclusive, which was a deliberate=
=

> decision in the language design. I don't know that the consequence of=
=

> being unable to specify an empty range was intended, though. Certainl=
y, =

> it couldn't be fixed by allowing a lower bound one greater than the =

> upper bound, which would just be two wrongs making something ugly (not=
=

> at all right).
>
> OCL has the empty-sequence literal for these cases; I guess that'll ha=
ve =

> to do.
>
> Cheers,
>
> Christian
>
> Artem Tikhomirov wrote:
>> Hello,
>> Sequence{'single-element'}->subSequence(2, 1) evaluates to null, not=
=

>> invalid as one might expect. Null, as a legal value, might get mixed =
=

>> with other values being collected along with the incorrect subSequen=
ce =

>> expression, and tracing such problem might be quite tricky. I wonder =
if =

>> OCL spec mandates null for such cases (I didn't find anything, =

>> however) or if there's reason to have null.
>> As a side note, it looks odd to me one can't use subSequence to end =
up =

>> with empty collection. Is there any design rationale behind that as =

>> well?
>>



-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Sequence.subSequence with invalid arguments [message #61076 is a reply to message #61053] Wed, 20 August 2008 19:40 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Hi, Radek,

Yes, I suspect that the terminology "undefined" in this case is a
throw-back to when "null" was called "OclUndefined." It doesn't help,
though, that "invalid" also responds true to oclIsUndefined(), in
addition to "null."

However, the fact that Sequence->first() returns null is consistent with
the fact that a null scalar is coerced to an empty set by the ->asSet()
operation. So, I don't like to mess with that.

Indexing out of bounds with at(Integer) is more clear-cut, though,
because the "at" operation has explicit constraints on the index. It's
too bad that the first() and last() operations are defined in terms of
at(), because that means that they must fail (with invalid) on empty
collections. A contradiction with some of the discussion in the spec.

So, gather the scenarios that you find problematic in a bug, and we can
resolve them in the 1.3/2.0 release. I hesitate to change the behaviour
of these operations in the maintenance branch; clients may have the
opposite expectations.

cW

Radek Dvorak wrote:
> Hi Christian,
>
> It seems that subSequence(...) is not the only case where invalid would
> be a more
> appropriate return value.
> For instance, Sequence::at(Integer) operation if called with an index
> out of bounds
> should give invalid rather then null IMO.
> If not, it might appear that null element exists at that position.
>
> Consequently, first(), last() operations seem affected too as
> Sequence{}->first() = Sequence{}->including(null)->first()
> might confuse things a bit.
>
> However, the OMG spec says, "->first() element of an empty collection
> will result in undefined.",
> though in a bit strange place for this operation contract ;).
>
> I can surely raise a bugzilla if you agree it's something to be fixed.
>
> Regards,
> /Radek

-----8<-----
Re: Sequence.subSequence with invalid arguments [message #61194 is a reply to message #60985] Fri, 22 August 2008 08:56 Go to previous messageGo to next message
Eclipse User
Originally posted by: artem.borland.com

Submitted https://bugs.eclipse.org/bugs/show_bug.cgi?id=244946

Empty sequence literal might not be a proper solution, e.g. when there's a
sub-sequence processing recursion, with the stop condition being empty
sequence. Given spec restriction stop condition needs to respect both
size() = 1 and size() = 0, which is not such a big deal, although tedious.


Christian W. Damus wrote:

> Hi, Artem,

> I would expect invalid in the case of subSequence(2, 1) because that
> violates a pre-condition constraint of the Sequence::subsequence()
> operation. Please raise a bug for this.

> Yes, it is odd that one cannot take an empty sub-sequence. That's a
> consequence of the upper bound being inclusive, which was a deliberate
> decision in the language design. I don't know that the consequence of
> being unable to specify an empty range was intended, though. Certainly,
> it couldn't be fixed by allowing a lower bound one greater than the
> upper bound, which would just be two wrongs making something ugly (not
> at all right).

> OCL has the empty-sequence literal for these cases; I guess that'll have
> to do.

> Cheers,

> Christian

> Artem Tikhomirov wrote:
>> Hello,
>>
>> Sequence{'single-element'}->subSequence(2, 1) evaluates to null, not
>> invalid as one might expect. Null, as a legal value, might get mixed
>> with other values being collected along with the incorrect subSequence
>> expression, and tracing such problem might be quite tricky. I wonder if
>> OCL spec mandates null for such cases (I didn't find anything, however)
>> or if there's reason to have null.
>>
>> As a side note, it looks odd to me one can't use subSequence to end up
>> with empty collection. Is there any design rationale behind that as well?
>>
Re: Sequence.subSequence with invalid arguments [message #61219 is a reply to message #61194] Fri, 22 August 2008 09:19 Go to previous message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Thanks, Artem.

We're used to tedious, long-winded OCL expressions, aren't we? It's a
natural consequence of a small language. Just imagine: it could have
been Lisp!

;-)

Artem Tikhomirov wrote:
> Submitted https://bugs.eclipse.org/bugs/show_bug.cgi?id=244946
>
> Empty sequence literal might not be a proper solution, e.g. when there's
> a sub-sequence processing recursion, with the stop condition being empty
> sequence. Given spec restriction stop condition needs to respect both
> size() = 1 and size() = 0, which is not such a big deal, although tedious.
>
>
> Christian W. Damus wrote:


-----8<-----
Previous Topic:Calling overriding methods
Next Topic:If-expressions
Goto Forum:
  


Current Time: Wed Jul 30 05:25:51 EDT 2014

Powered by FUDForum. Page generated in 0.01621 seconds