| Additional Operations collision [message #60247] |
Mon, 04 August 2008 11:01  |
Eclipse User |
|
|
|
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 11:13  |
| 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
|
|
|
Powered by
FUDForum. Page generated in 0.04613 seconds
Home