Home » Modeling » OCL » implementation for checking invalid select expressions
|
| Re: implementation for checking invalid select expressions [message #55901 is a reply to message #55874] |
Thu, 15 May 2008 19:34   |
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 21:50 |
 Felix Dorner
Messages: 676
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] |
Fri, 16 May 2008 00:19 |
| 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
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 09:59:37 GMT 2024
Powered by FUDForum. Page generated in 0.03148 seconds |
] 
Search
Help
Register
Login
Home
