Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » implementation for checking invalid select expressions
implementation for checking invalid select expressions [message #55874] Thu, 15 May 2008 15:09 Go to next message
Felix Dorner is currently offline Felix Dorner
Messages: 675
Registered: July 2009
Senior Member
Hey,

Suppose I have a Set of Integers, and call the following:

theSet->select( x | x.contains("abc"));

Which is the error that's spit out:

a) Undefined Operation "contains" for type "Integer" (the type of x is assumed
to be Integer from the context)

b) Argument { String => Boolean } cannot be applied to function select of type
"set<Integer>"?

Is this just implementation-specific? Would one speak of "type inference" in
both cases?

Thanks,
Felix
Re: implementation for checking invalid select expressions [message #55901 is a reply to message #55874] Thu, 15 May 2008 15:34 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Hi, Felix,

It would be hard for an OCL implementation to supply message (b)
because, as the Integer type doesn't have a "contains" operation, there
is not reason to suppose that its result value might be String.
Although, I'm not sure that I understand what you mean by

{ String => Boolean }

in your description.

I would generally expect something like the message (a)

HTH,

Christian


Felix Dorner wrote:
> Hey,
>
> Suppose I have a Set of Integers, and call the following:
>
> theSet->select( x | x.contains("abc"));
>
> Which is the error that's spit out:
>
> a) Undefined Operation "contains" for type "Integer" (the type of x is
> assumed to be Integer from the context)
>
> b) Argument { String => Boolean } cannot be applied to function select
> of type "set<Integer>"?
>
> Is this just implementation-specific? Would one speak of "type
> inference" in both cases?
>
> Thanks,
> Felix
>
Re: implementation for checking invalid select expressions [message #55954 is a reply to message #55901] Thu, 15 May 2008 17:50 Go to previous messageGo to next message
Felix Dorner is currently offline Felix Dorner
Messages: 675
Registered: July 2009
Senior Member
Christian W. Damus wrote:
> Hi, Felix,
>
> It would be hard for an OCL implementation to supply message (b)
> because, as the Integer type doesn't have a "contains" operation
> is not reason to suppose that its result value might be String.
> Although, I'm not sure that I understand what you mean by
>
> { String => Boolean }
>
> in your description.
>
> I would generally expect something like the message (a)

At some point during the parsing, the "x" (in the expression part) must be
assigned a type. From your response, I derive that this x is simply by
definition an "Integer", because it's used as the iterator for a set of Integers...

With {String => Boolean } I mean something like a closure (or a function),
taking a String as an argument and returning a Boolean. I somehow see
parallelities in iterator expressions and function arguments, although the OCL
specification does not mention this relationship (afaik). So select respective
collect operations for collections containing elements of type T can be seen as
functions that take arguments of type {T => Boolean}, respective {T=>V} where V
is simply "any Type", similar to generic operations.
Re: implementation for checking invalid select expressions [message #55980 is a reply to message #55954] Thu, 15 May 2008 20:19 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Hi, Felix,

I see. Yes, the type of x is, implicitly, the element type of the
source collection of the select expression. This implicit type is
explicitly defined as such by OCL :-)

I see the body expressions of iterators as more like block closures
than function objects, because they have access to the variables in
the enclosing context. Rather like Smalltalk's iteration methods on
collections.

I hope that, between us, we have answered your original question?

cW

On Thursday 05-15-2008 (05:50), Felix Dorner wrote:
> Christian W. Damus wrote:
>> Hi, Felix,
>>
>> It would be hard for an OCL implementation to supply message (b)
>> because, as the Integer type doesn't have a "contains" operation
>> is not reason to suppose that its result value might be String.
>> Although, I'm not sure that I understand what you mean by
>>
>> { String => Boolean }
>>
>> in your description.
>>
>> I would generally expect something like the message (a)

> At some point during the parsing, the "x" (in the expression part)
> must be assigned a type. From your response, I derive that this x is
> simply by definition an "Integer", because it's used as the iterator
> for a set of Integers...

> With {String => Boolean } I mean something like a closure (or a
> function), taking a String as an argument and returning a Boolean. I
> somehow see parallelities in iterator expressions and function
> arguments, although the OCL specification does not mention this
> relationship (afaik). So select respective collect operations for
> collections containing elements of type T can be seen as functions
> that take arguments of type {T => Boolean}, respective {T=>V} where V
> is simply "any Type", similar to generic operations.


--

I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo
Re: implementation for checking invalid select expressions [message #56007 is a reply to message #55980] Fri, 16 May 2008 05:40 Go to previous message
Felix Dorner is currently offline Felix Dorner
Messages: 675
Registered: July 2009
Senior Member
Hi Christian,

> I see the body expressions of iterators as more like block closures
> than function objects, because they have access to the variables in
> the enclosing context. Rather like Smalltalk's iteration methods on
> collections.
I was imprecise, I mean exactly that.

>
> I hope that, between us, we have answered your original question?

Yes :)
Previous Topic:Problem while validating TupleLiteralParts (checkValuePart constraint)
Next Topic:Bug in OCLAbstractAnalyzer
Goto Forum:
  


Current Time: Fri Aug 22 10:00:39 EDT 2014

Powered by FUDForum. Page generated in 0.01531 seconds