[news.eclipse.modeling.mdt.uml2.ocl] Re: Calling static operations in OC

["Christian W. Damus" <cdamus@xxxxxxxxxx>]

Hi, Radek,

That looks like something introduced into the (recently released) official
2.0 specification; the previous interim revision on which EMFT 1.0 was
implemented didn't have this (IIRC; I may be wrong).

In any case, what is currently supported is:

   myPackage::MyClass.operation()

because this matches

   [C] OperationCallExpCS ::= OclExpressionCS â.â simpleNameCS
â(â argumentsCS? â)â

(although @pre obviously wouldn't apply, as in [E]).

This rule matches because the OclExpressionCS can match a TypeExpCS.

So, I think the dot notation should continue to be supported (it would be,
anyway, for compatibility), but the :: notation should be added.

Would you mind raising a bug?  This actually falls under an existing
catch-up-to-the-spec plan item, but it would be nice to track it
separately, too.

Thanks!

Christian


Radek Dvorak wrote:

> Hi,
> 
> When trying to parse operation call expression that invokes a static
> operation,
> 
>     myPackage::MyClass::operation()
> 
> I get the following error:
>     1:19:1:20 "+" expected instead of "::"
> (I would rather expect something like "(Cannot find operation
> (operation())" here.)
> 
> The OCL 2.0 spec mentions the following rule for this case.
> [G] OperationCallExpCS ::= pathNameCS '(' argumentsCS? ')
> 
> Keeping in mind that the 'Concrete Syntax' part of the spec is a bit
> outdated,
> I am asking this in the newsgroup first, before raising a bug.
> 
> Clearly, using a static operation does not make much sense if the target
> metamodel is 'ecore'.
> However, when targeting for instance UML metamodel, it could be useful.
> Also custom Environments supporting java <<utility>> classes would benefit
> from this.
> 
> Regards,
> /Radek