Eclipse Community Forums: OCL » Type of variable in "let" not agreeing with oclIsTypeOf/oclAsType

Home » Modeling » OCL » Type of variable in "let" not agreeing with oclIsTypeOf/oclAsType

Type of variable in "let" not agreeing with oclIsTypeOf/oclAsType [message #650539]

Tue, 25 January 2011 08:31

Eclipse User

While playing with my UML model and the interactive OCL console. Both OCL-functions convince me that I'm looking at a uml::Interface, but if I try to assign it to a variable of the same time in a let, it doesn't type-check. What am I missing? Platform is Helios-SR1 with feature OCL 3.0.1 and feature OCL for UML 3.0.0.

Evaluating:
self.supplier.getValue(self.supplier.getAppliedStereotype('r COS::ContractInterface')- >any(true),'interface').oclIsTypeOf(uml::Interface)
Results:
true

Evaluating:
self.supplier.getValue(self.supplier.getAppliedStereotype('r COS::ContractInterface')- >any(true),'interface').oclAsType(uml::Interface)
Results:
<Interface> Interface_From_Clock

Evaluating:
let i : uml::Interface = self.supplier.getValue(self.supplier.getAppliedStereotype('r COS::ContractInterface')- >any(true),'interface').oclAsType(uml::Interface) in i
Results:
Init expression type does not conform to type of variable (i).

Re: Type of variable in "let" not agreeing with oclIsTypeOf/oclAsType [message #650665 is a reply to message #650539]

Tue, 25 January 2011 17:44

Eclipse User

Hi Volker

This might be Bug 299959. Major simplification of associated code is
happening for 3.1.0 and you will get hover text in the editor to help
with type problems. I'm not sure this helps you now.

Regards

Ed Willink

On 25/01/2011 13:31, Volker Stolz wrote:
> While playing with my UML model and the interactive OCL console. Both
> OCL-functions convince me that I'm looking at a uml::Interface, but if
> I try to assign it to a variable of the same time in a let, it doesn't
> type-check. What am I missing? Platform is Helios-SR1 with feature OCL
> 3.0.1 and feature OCL for UML 3.0.0.
>
> Evaluating:
> self.supplier.getValue(self.supplier.getAppliedStereotype('r
> COS::ContractInterface')-
> >any(true),'interface').oclIsTypeOf(uml::Interface)
> Results:
> true
>
> Evaluating:
> self.supplier.getValue(self.supplier.getAppliedStereotype('r
> COS::ContractInterface')-
> >any(true),'interface').oclAsType(uml::Interface)
> Results:
> <Interface> Interface_From_Clock
>
> Evaluating:
> let i : uml::Interface =
> self.supplier.getValue(self.supplier.getAppliedStereotype('r
> COS::ContractInterface')-
> >any(true),'interface').oclAsType(uml::Interface) in i
> Results:
> Init expression type does not conform to type of variable (i).

Re: Type of variable in "let" not agreeing with oclIsTypeOf/oclAsType [message #650746 is a reply to message #650665]

Wed, 26 January 2011 06:09

Eclipse User

Hi Ed, it might be.

I just checked Indigo with OCL 3.1.0 M4, and it gives the same message...Please advise; (new) ticket?

-Volker

Re: Type of variable in "let" not agreeing with oclIsTypeOf/oclAsType [message #650821 is a reply to message #650746]

Wed, 26 January 2011 11:57

Eclipse User

Hi Volker

The fixes appear in M5 the new extensible Model-Driven Library, which
ensures that declarations and semantics are localised. It was too
difficult to pin down the corner cases in the old code, and even harder
to track OCL evolution (past), and more importantly future where many
unimplementable aspects of Complete OCL will be resolved.

Use org.eclipse.ocl.examples.pivot... which will be promoted to
org.eclipse.ocl.pivot... in 4.0.

Please raise a Bugzilla, if you can attach small complete repro models;
that will ensure that I check it. Providing the UML aspects of the new
code is still work in progress; test cases welcome.

Regards

Ed Willink

On 26/01/2011 11:09, Volker Stolz wrote:
> Hi Ed, it might be.
>
> I just checked Indigo with OCL 3.1.0 M4, and it gives the same
> message...Please advise; (new) ticket?
>
> -Volker

Re: Type of variable in "let" not agreeing with oclIsTypeOf/oclAsType [message #650823 is a reply to message #650665]

Wed, 26 January 2011 12:40

Eclipse User

Hm, I've found a kind of workaround:

let i : uml::Interface = self.supplier.getValue(self.supplier.getAppliedStereotype('rCOS::ContractInterface')->any(true),'interface')->any(true).oclAsType(uml::Interface) in i

It looks like it may actually be my fault since accessing the stereotype with getValue() yields an EJavaObject in Ecore, and I'm not sure if I should expect OCL to find out that the stereotype actually has exactly-once multiplicity. The additional "any(true)" will do the right thing here.

Volker

[Updated on: Wed, 26 January 2011 12:56] by Moderator

Re: Type of variable in "let" not agreeing with oclIsTypeOf/oclAsType [message #650836 is a reply to message #650823]

Wed, 26 January 2011 13:22

Eclipse User

Hi Volker

On 26/01/2011 17:40, Volker Stolz wrote:
> Hm, I've found a kind of workaround:
>
Good. I forhot to ask whty you were using getXXX? This is usually
indicating an attempt to use Ecore synthesized methods rather than
modeled methods.
> let i : uml::Interface =
> self.supplier.getValue(self.supplier.getAppliedStereotype('r COS::ContractInterface')- >any(true),'interface')->any(true).oclAsType(uml::Interface)
> in i
>
> It looks like it may actually be my fault since accessing the
> stereotype with getValue() yields an EJavaObject in Ecore, and I'm not
> sure if I should expect OCL to find out that the stereotype actually
> has exactly-once multiplicity.
>
Another source of difficulties with the old code. The new code has all
values extending Value, which provides a clear locality for multiplicity
semantic resolutions. You should always get an error to help you.

Regards

Ed Willink

> Volker

Re: Type of variable in "let" not agreeing with oclIsTypeOf/oclAsType [message #651010 is a reply to message #650836]

Thu, 27 January 2011 07:49

Eclipse User

Ed, indeed, we'd like to switch from the OCL ecore environment factory to the UML factory, in which case this problem would not have occurred because we'd be using

supplier.oclAsType(Interface).extension_contractinterface.interface

But this rule is part of a whole collection in a larger framework where some depend on the Ecore factory, as we use e.g. getRelationships(). I guess I could start by splitting them up into those that can already be moved to UML, like this one.

Thanks for the hint about M5, I'll take a look at it and see if it will required further action!

-Volker

Re: Type of variable in "let" not agreeing with oclIsTypeOf/oclAsType [message #653525 is a reply to message #650836]

Thu, 10 February 2011 01:42

Eclipse User

Hi Ed, a note:
I get the same error with OCL 3.1.0 20110131.

-Volker

Re: Type of variable in "let" not agreeing with oclIsTypeOf/oclAsType [message #653545 is a reply to message #653525]

Thu, 10 February 2011 03:39

Eclipse User

Hi Volker

The fix should be in the new UML-based pivot model approach in OCL 3.1.0
M5 Examples.

Can you let me have some example files so that I can check it out?

Regards

Ed

On 10/02/2011 06:42, Volker Stolz wrote:
> Hi Ed, a note:
> I get the same error with OCL 3.1.0 20110131.
>
> -Volker

Re: Type of variable in "let" not agreeing with oclIsTypeOf/oclAsType [message #654374 is a reply to message #653545]

Tue, 15 February 2011 08:47

Eclipse User

Hi Ed, self-contained minimal profile, model and unit tests:

http://heim.ifi.uio.no/~stolz/ocl-issue.zip

-Volker

Re: Type of variable in "let" not agreeing with oclIsTypeOf/oclAsType [message #654420 is a reply to message #654374]

Tue, 15 February 2011 12:03

Eclipse User

Hi Volker

Thanks. That also gives me a simple UML example to work with.
Unfortunately I've got some way tp go to sort this out with the pivot
model. I've filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=337230
Hopefully this'll be fully fixed for Indigo.

Regards

Ed Willink

On 15/02/2011 13:47, Volker Stolz wrote:
> Hi Ed, self-contained minimal profile, model and unit tests:
>
> http://heim.ifi.uio.no/~stolz/ocl-issue.zip
>
> -Volker

Previous Topic:	OCLs for abstract classes and children
Next Topic:	toLower() or toLowerCase()

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jul 22 14:30:06 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter