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]]>

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

>]]>

>

> 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.]]>

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]]>

> 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 :)]]>