Hi Elio, Ed
[Ed: you may be able to provide a simple solution for b).]
a) parser modification
The parser is intended to be extended rather than modified. Be very wary
of modifying; you will have te re-engineer each time MDT-OCL improves.
That said we are in the process of migrating from LPG 1 to LPG 2,
https://bugs.eclipse.org/bugs/show_bug.cgi?id=242153, which will require
about four trivial edit procedures to existing extensions.
b) operators
In your Ecore model of custom data types (EClass not EDataType) you can
add operations such as "+", which you can then use them naturally in
OCL. Unfortunately these give a validation error in EMF so you cannot
genModel them.
I'm not sure if the situation is any better for a UML model.
This is a spelling problem I've been considering already: For OCL it
must be "+" for Java it must be perhaps "_plus". (OMG) OCL needs to
specify an encoding scheme for awkward characters and to specify a
concrete syntax access scheme. MDT-OCL supports access via double quotes
e.g:
def: "+"(d : Date) ...
I'm afraid I don't know of any solution to making Date + Date work today.
The XSD support for EMF provides a form of renaming. I've copied this to
Ed Merks who may be able to explain how it could be exploited.
c) call path
I'm not very familiar with the EvaluationEnvironment, so nearly all of
what I'm about to suggest may already be the current MDT-OCL functionality.
You can introduce a derived LOTREnvironment which is created at each
stage of evaluation, with a reference to its outer context. At any point
these references give you the call path. You can then add custom methods
to evaluate any function of the call path that you like. Perhaps you
encapsulate these all in a richer Environment object and implement just
a single .oclEnvironment() method to access it. If you get this working
it might make for a useful contribution to MDT-OCL and a submission for
a future OCL specification.
Regards
Ed Willink
Elio Damaggio wrote:
> Hi all,
>
> I am modifying the OCL parser/evaluator in order to (besides other things):
>
> * include a series of time related datatypes (Date, Time, Duration,
> Timestamp). These datatypes should have standard infix operators (+, -,
> ..) like integers and so on... I think I have to modify the
> EvaluationVisitor. Is this the best course of action?
>
> * include predefined methods that, if applied on an attribute, have
> access to the model information of that attribute (i.e. which class they
> belong, in addition to the actual instance).
> For instance, lets assume book have an attribute called author. And the
> "LOTR" book instance has "Tolkien" as its author attribute. Then the
> predefined method LOTR.author.info() should be able to know that it is
> invoked on the "author" attribute of a "book" class.
> Do you have any idea on how to implement these methods?
>
> Thank you all,
>
> Elio
>