Hi Christian,
I was able to have the operator work :)
How is the situation for unary operators?
Is there a way to define those for custom datatypes?
Thanks,
Elio
Christian W. Damus wrote:
> Hi, Ed, Elio,
> Yes, OCL is trained to look for Java names "plus", "minus", "lessThan",
> "greaterThan", etc. to implement these symbolic operators, but it does
> expect to find the symbolic names (e.g., "+", "<") in the model's
> EClass. The "<" / "lessThan" operation is particularly handy because it
> allows your type to be used in "orderedBy" iterators.
> One of the callOperation() or some such methods in the
> EvaluationEnvironment type hierarchy has the mapping from symbolic to
> Java names, in looking up the Method objects to invoke reflectively. I
> should, of course, have documented it in the SDK's developer guide,
> too :-(
> Cheers,
> Christian
> On Sat, 2009-08-29 at 06:52 +0100, Ed Willink wrote:
>> 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
>> >