Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Additional Operations collision
Additional Operations collision [message #60247] Mon, 04 August 2008 15:01 Go to next message
Laurent Goubet is currently offline Laurent Goubet
Messages: 1632
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------090907080007050301050009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Christian,

While implementing the MTL standard library, I stumbled upon yet another
problem with the current OCL implementation (or so I think). You
provided a way to provide additional EOperations to both parsing and
evaluation through the environment's "AddHelperOperation" method, but we
_cannot_ provide additional operations which names conflict with
existing operations.

In fact, the MTL specification defines both a "first(int)" and
"last(int)" additional operation on the primitive type "String", yet
operations of these names already happen to exist on some primitive
types (at least they do exist on OrderedSet(T)). Thus when evaluating
them, the default EvaluationVisitor finds an operation code > 0 and
assumes it is a predefined operation even though neither parameters- nor
source- types match. This results in the EvaluationEnvironment's
"callOperation" not being called and my custom operation not being
evaluated as expected.

I could of course override the visitor's "visitOperationCallExp" and
duplicate part of its logic to inline my operations if the annotation I
use to define my EOperations is present ... but it doesn't feel right to
have the evaluation split in two (part of it being in the
EvaluationEnvironment, the rest in the EvaluationVisitor.

What would be the accurate way of providing additional methods of the such?

Thanks

Laurent Goubet
Obeo

--------------090907080007050301050009
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="laurent_goubet.vcf"

begin:vcard
fn:Laurent Goubet
n:Goubet;Laurent
org:<a href="http://www.obeo.fr/">Obeo</a>
email;internet:laurent.goubet@obeo.fr
url:http://www.obeo.fr
version:2.1
end:vcard


--------------090907080007050301050009--
Re: Additional Operations collision [message #60272 is a reply to message #60247] Mon, 04 August 2008 15:13 Go to previous message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Hi, Laurent,

This is not good. The parser should not assign opcodes to an
OperationCallExp that does not actually call an OCL Standard Library
operation.

Would you mind raising a bug with your test case?

In the mean-time, you should be able to work around this problem in an
MTLEvaluationEnvironment. The overrides(...) method of the environment
is always invoked to ask whether the environment overrides a standard
operation (identified by its opcode). You can implement the
overrides(...) operation to check for the "first" and "last" opcodes and
return true if the operation signature looks like one of your string
operations.

HTH,

Christian


laurent Goubet wrote:
> Christian,
>
> While implementing the MTL standard library, I stumbled upon yet another
> problem with the current OCL implementation (or so I think). You
> provided a way to provide additional EOperations to both parsing and
> evaluation through the environment's "AddHelperOperation" method, but we
> _cannot_ provide additional operations which names conflict with
> existing operations.
>
> In fact, the MTL specification defines both a "first(int)" and
> "last(int)" additional operation on the primitive type "String", yet
> operations of these names already happen to exist on some primitive
> types (at least they do exist on OrderedSet(T)). Thus when evaluating
> them, the default EvaluationVisitor finds an operation code > 0 and
> assumes it is a predefined operation even though neither parameters- nor
> source- types match. This results in the EvaluationEnvironment's
> "callOperation" not being called and my custom operation not being
> evaluated as expected.
>
> I could of course override the visitor's "visitOperationCallExp" and
> duplicate part of its logic to inline my operations if the annotation I
> use to define my EOperations is present ... but it doesn't feel right to
> have the evaluation split in two (part of it being in the
> EvaluationEnvironment, the rest in the EvaluationVisitor.
>
> What would be the accurate way of providing additional methods of the such?
>
> Thanks
>
> Laurent Goubet
> Obeo
Previous Topic:Define custom operations on primitive types
Next Topic:[Announce] MDT OCL 1.3.0 I200808061438 is available
Goto Forum:
  


Current Time: Thu Oct 23 00:04:14 GMT 2014

Powered by FUDForum. Page generated in 0.02202 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software