Eclipse Community Forums: OCL » Custom OCLExpression implementations

Home » Modeling » OCL » Custom OCLExpression implementations

Custom OCLExpression implementations [message #57376]

Fri, 30 May 2008 04:49

Eclipse User

This is a multi-part message in MIME format.
--------------050406010507050601070008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Christian,

I think you've already had some discussions with Jonathan about MTL and
the way we are trying to use the OCL plugin for its implementation.

I was messing around with it and encountered some critical issues when
trying to evaluate MTL's expressions through the OCL plugin. We have
many "custom" implementations of OCLExpressions for MTL as specified in
the OMG specifications, but I will focus here on the "Template" class.

This "Template" class implements org.eclipse.ocl.ecore.OCLExpression so
we were hoping the evaluation would come easily through code such as

OCL<?, EClassifier, ?, ?, ?, ?, ?, ?, ?, Constraint, EClass, EObject>
ocl = OCL.newInstance(EcoreEnvironmentFactory.INSTANCE);
Query<?, ?, ?> query = ocl.createQuery(template);
query.evaluate();

Yet it did not do the trick. We must implement the accept() method of
OCLExpression in "Template" for the visitor to be able to evaluate our
expression. The signature of this accept() method looks like :
<T, U extends Visitor<T, ?, ?, ?, ?, ?, ?, ?, ?, ?>> T accept(U v);

As we cannot instantiate a "T" for the return type, the only solution is
to call one of the parameter visitor's "visitXXX" methods. And here is
the issue : the "Visitor" interface cannot be overriden by third-party
plugins, yet it provides no "visitXXX" method for my custom
OCLExpression since it doesn't know about it.

How can I work my way around this problem in order for the OCL plugin to
be able to evaluate MTL expressions? The only solution I found so far
was to create my own EnvironmentFactory implementation (I extending
EcoreEnvironmentFactory to avoid the hassle of reimplementing
everything) and override its "createEvaluationVisitor" method to return
a custom visitor.

Yet again this approach doesn't fully satisfies me since I need to
*fully* reimplement a visitor for *all* OCLExpressions and this isn't
possible for the average human (just look at that
"visitOperationCallExp()"!! I can't imagine the headaches you had
implementing this). Couldn't you open the implementation of
org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl so that a
third-party plugin can add its own logic to evaluate expressions?

Obviously, this is only the way *I* understood the implementation, I
could have missed something that would have been much easier to meet my
needs. I guess I'll be waiting for your input on this :).

Thanks for reading through this.

Laurent Goubet
Obeo

--------------050406010507050601070008
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

--------------050406010507050601070008--

Re: Custom OCLExpression implementations [message #57402 is a reply to message #57376]

Fri, 30 May 2008 08:25

Eclipse User

Originally posted by: cdamus.zeligsoft.com

--=-Q6L6hCcJNMPoPzg1JXP2
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Laurent,

See some replies in-line, below.

HTH,

Christian

On Fri, 2008-05-30 at 10:49 +0200, laurent Goubet wrote:

> Hi Christian,
>
> I think you've already had some discussions with Jonathan about MTL and
> the way we are trying to use the OCL plugin for its implementation.

Yes, I have, at EclipseCon if I remember correctly. We missed an
opportunity, though, to discuss the matter in greater depth.

> I was messing around with it and encountered some critical issues when
> trying to evaluate MTL's expressions through the OCL plugin. We have
> many "custom" implementations of OCLExpressions for MTL as specified in
> the OMG specifications, but I will focus here on the "Template" class.
>
> This "Template" class implements org.eclipse.ocl.ecore.OCLExpression so
> we were hoping the evaluation would come easily through code such as
>
> OCL<?, EClassifier, ?, ?, ?, ?, ?, ?, ?, Constraint, EClass, EObject>
> ocl = OCL.newInstance(EcoreEnvironmentFactory.INSTANCE);
> Query<?, ?, ?> query = ocl.createQuery(template);
> query.evaluate();
>
> Yet it did not do the trick. We must implement the accept() method of
> OCLExpression in "Template" for the visitor to be able to evaluate our
> expression. The signature of this accept() method looks like :
> <T, U extends Visitor<T, ?, ?, ?, ?, ?, ?, ?, ?, ?>> T accept(U v);
>
> As we cannot instantiate a "T" for the return type, the only solution is

What do you mean by "instantiate a 'T'"? The usual substitution for an
evaluation visitor would probably be Object.

> to call one of the parameter visitor's "visitXXX" methods. And here is
> the issue : the "Visitor" interface cannot be overriden by third-party
> plugins, yet it provides no "visitXXX" method for my custom
> OCLExpression since it doesn't know about it.

Yes, the Visitor pattern is not known for being friendly to
specialization.

> How can I work my way around this problem in order for the OCL plugin to
> be able to evaluate MTL expressions? The only solution I found so far
> was to create my own EnvironmentFactory implementation (I extending
> EcoreEnvironmentFactory to avoid the hassle of reimplementing
> everything) and override its "createEvaluationVisitor" method to return
> a custom visitor.

That is probably the first approach that I would try, if I were in your
position.

> Yet again this approach doesn't fully satisfies me since I need to
> *fully* reimplement a visitor for *all* OCLExpressions and this isn't
> possible for the average human (just look at that
> "visitOperationCallExp()"!! I can't imagine the headaches you had

Heh heh ... I didn't implement this. That visitor was implemented
before the OCL interpreter came to me, as long as six years ago. It
works, and I haven't yet had a compelling reason to reorganize it.

> implementing this). Couldn't you open the implementation of
> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl so that a
> third-party plugin can add its own logic to evaluate expressions?

The opening-up of the API for extensibility of the language has been a
gradual process, starting in the 1.2 release with a bunch of work items
to support QVT (which doesn't much extend the expression language as
such, but more the placement of OCL expressions).

Have you had a look at the org.eclipse.ocl.EvaluationVisitorDecorator
class? It is used to hook into the visitXyz() methods of the evaluation
visitor. The TracingEvaluationVisitor illustrates how it works, for
tracing the evaluation of an OCLExpression sub-expression by
sub-expression (this is used when you enable the "evaluation" tracing
option at run-time). The EvaluationVisitor ensures that it always
delegates calls to its decorator if it has one. Because the
EvaluationVisitorDecorator delegates all of its visitation methods, by
default, to the visitor that it decorates, you should be able to
specialize it to add the visitation methods that you need for your
specialized OCLExpressions. At least, that is how it is intended to
work ... :-)

> Obviously, this is only the way *I* understood the implementation, I
> could have missed something that would have been much easier to meet my
> needs. I guess I'll be waiting for your input on this :).
>
> Thanks for reading through this.
>
> Laurent Goubet
> Obeo

--=-Q6L6hCcJNMPoPzg1JXP2
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Laurent, 
 
See some replies in-line, below. 
 
HTH, 
 
Christian 
 
 
On Fri, 2008-05-30 at 10:49 +0200, laurent Goubet wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Christian,

I think you've already had some discussions with Jonathan about MTL and 
the way we are trying to use the OCL plugin for its implementation.
</PRE>
</BLOCKQUOTE>
 
Yes, I have, at EclipseCon if I remember correctly.  We missed an opportunity, though, to discuss the matter in greater depth.
<PRE>

</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
I was messing around with it and encountered some critical issues when 
trying to evaluate MTL's expressions through the OCL plugin. We have 
many "custom" implementations of OCLExpressions for MTL as specified in 
the OMG specifications, but I will focus here on the "Template" class.

This "Template" class implements org.eclipse.ocl.ecore.OCLExpression so 
we were hoping the evaluation would come easily through code such as

OCL<?, EClassifier, ?, ?, ?, ?, ?, ?, ?, Constraint, EClass, EObject> 
ocl = OCL.newInstance(EcoreEnvironmentFactory.INSTANCE);
Query<?, ?, ?> query = ocl.createQuery(template);
query.evaluate();

Yet it did not do the trick. We must implement the accept() method of 
OCLExpression in "Template" for the visitor to be able to evaluate our 
expression. The signature of this accept() method looks like :
<T, U extends Visitor<T, ?, ?, ?, ?, ?, ?, ?, ?, ?>> T accept(U v);

As we cannot instantiate a "T" for the return type, the only solution is 
</PRE>
</BLOCKQUOTE>
 
What do you mean by "instantiate a 'T'"?  The usual substitution for an evaluation visitor would probably be Object. 
 
<BLOCKQUOTE TYPE=CITE>
<PRE>
to call one of the parameter visitor's "visitXXX" methods. And here is 
the issue : the "Visitor" interface cannot be overriden by third-party 
plugins, yet it provides no "visitXXX" method for my custom 
OCLExpression since it doesn't know about it.
</PRE>
</BLOCKQUOTE>
 
Yes, the Visitor pattern is not known for being friendly to specialization.
<PRE>

</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
How can I work my way around this problem in order for the OCL plugin to 
be able to evaluate MTL expressions? The only solution I found so far 
was to create my own EnvironmentFactory implementation (I extending 
EcoreEnvironmentFactory to avoid the hassle of reimplementing 
everything) and override its "createEvaluationVisitor" method to return 
a custom visitor.
</PRE>
</BLOCKQUOTE>
 
That is probably the first approach that I would try, if I were in your position.
<PRE>

</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Yet again this approach doesn't fully satisfies me since I need to 
*fully* reimplement a visitor for *all* OCLExpressions and this isn't 
possible for the average human (just look at that 
"visitOperationCallExp()"!! I can't imagine the headaches you had 
</PRE>
</BLOCKQUOTE>
 
Heh heh ... I didn't implement this.  That visitor was implemented before the OCL interpreter came to me, as long as six years ago.  It works, and I haven't yet had a compelling reason to reorganize it. 
 
<BLOCKQUOTE TYPE=CITE>
<PRE>
implementing this). Couldn't you open the implementation of 
org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl so that a 
third-party plugin can add its own logic to evaluate expressions?
</PRE>
</BLOCKQUOTE>
 
The opening-up of the API for extensibility of the language has been a gradual process, starting in the 1.2 release with a bunch of work items to support QVT (which doesn't much extend the expression language as such, but more the placement of OCL expressions). 
 
Have you had a look at the org.eclipse.ocl.EvaluationVisitorDecorator class?  It is used to hook into the visitXyz() methods of the evaluation visitor.  The TracingEvaluationVisitor illustrates how it works, for tracing the evaluation of an OCLExpression sub-expression by sub-expression (this is used when you enable the "evaluation" tracing option at run-time).  The EvaluationVisitor ensures that it always delegates calls to its decorator if it has one.  Because the EvaluationVisitorDecorator delegates all of its visitation methods, by default, to the visitor that it decorates, you should be able to specialize it to add the visitation methods that you need for your specialized OCLExpressions.  At least, that is how it is intended to work  ... :-) 
 
<BLOCKQUOTE TYPE=CITE>
<PRE>
Obviously, this is only the way *I* understood the implementation, I 
could have missed something that would have been much easier to meet my 
needs. I guess I'll be waiting for your input on this :).

Thanks for reading through this.

Laurent Goubet
Obeo
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-Q6L6hCcJNMPoPzg1JXP2--

Re: Custom OCLExpression implementations [message #57428 is a reply to message #57402]

Fri, 30 May 2008 09:15

Eclipse User

This is a multi-part message in MIME format.
--------------070908070904040605030905
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Christian,

comments below.

Laurent Goubet
Obeo

Christian W. Damus a écrit :
> Hi, Laurent,
>
> See some replies in-line, below.
>
> HTH,
>
> Christian
>
>
> On Fri, 2008-05-30 at 10:49 +0200, laurent Goubet wrote:
>> Hi Christian,
>>
>> I think you've already had some discussions with Jonathan about MTL and
>> the way we are trying to use the OCL plugin for its implementation.
>
> Yes, I have, at EclipseCon if I remember correctly. We missed an
> opportunity, though, to discuss the matter in greater depth.
>
>
>> I was messing around with it and encountered some critical issues when
>> trying to evaluate MTL's expressions through the OCL plugin. We have
>> many "custom" implementations of OCLExpressions for MTL as specified in
>> the OMG specifications, but I will focus here on the "Template" class.
>>
>> This "Template" class implements org.eclipse.ocl.ecore.OCLExpression so
>> we were hoping the evaluation would come easily through code such as
>>
>> OCL<?, EClassifier, ?, ?, ?, ?, ?, ?, ?, Constraint, EClass, EObject>
>> ocl = OCL.newInstance(EcoreEnvironmentFactory.INSTANCE);
>> Query<?, ?, ?> query = ocl.createQuery(template);
>> query.evaluate();
>>
>> Yet it did not do the trick. We must implement the accept() method of
>> OCLExpression in "Template" for the visitor to be able to evaluate our
>> expression. The signature of this accept() method looks like :
>> <T, U extends Visitor<T, ?, ?, ?, ?, ?, ?, ?, ?, ?>> T accept(U v);
>>
>> As we cannot instantiate a "T" for the return type, the only solution is
>
> What do you mean by "instantiate a 'T'"? The usual substitution for an
> evaluation visitor would probably be Object.
>
I simply meant that there is no way to evaluate the OCLExpression from
"accept" save for delegating to the visitor since we cannot instantiate
Objects of the generic type "T" whatever it is (the compiler wouldn't
accept to cast "Object" to "T" either so we cannot simple return an Object).
>
>> to call one of the parameter visitor's "visitXXX" methods. And here is
>> the issue : the "Visitor" interface cannot be overriden by third-party
>> plugins, yet it provides no "visitXXX" method for my custom
>> OCLExpression since it doesn't know about it.
>
> Yes, the Visitor pattern is not known for being friendly to specialization.
>
>
>> How can I work my way around this problem in order for the OCL plugin to
>> be able to evaluate MTL expressions? The only solution I found so far
>> was to create my own EnvironmentFactory implementation (I extending
>> EcoreEnvironmentFactory to avoid the hassle of reimplementing
>> everything) and override its "createEvaluationVisitor" method to return
>> a custom visitor.
>
> That is probably the first approach that I would try, if I were in your
> position.
>
>
>> Yet again this approach doesn't fully satisfies me since I need to
>> *fully* reimplement a visitor for *all* OCLExpressions and this isn't
>> possible for the average human (just look at that
>> "visitOperationCallExp()"!! I can't imagine the headaches you had
>
> Heh heh ... I didn't implement this. That visitor was implemented
> before the OCL interpreter came to me, as long as six years ago. It
> works, and I haven't yet had a compelling reason to reorganize it.
>
I can understant that. I think it would take a _really_ good reason to
do it ^^.
>
>> implementing this). Couldn't you open the implementation of
>> org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl so that a
>> third-party plugin can add its own logic to evaluate expressions?
>
> The opening-up of the API for extensibility of the language has been a
> gradual process, starting in the 1.2 release with a bunch of work items
> to support QVT (which doesn't much extend the expression language as
> such, but more the placement of OCL expressions).
>
> Have you had a look at the org.eclipse.ocl.EvaluationVisitorDecorator
> class? It is used to hook into the visitXyz() methods of the evaluation
> visitor. The TracingEvaluationVisitor illustrates how it works, for
> tracing the evaluation of an OCLExpression sub-expression by
> sub-expression (this is used when you enable the "evaluation" tracing
> option at run-time). The EvaluationVisitor ensures that it always
> delegates calls to its decorator if it has one. Because the
> EvaluationVisitorDecorator delegates all of its visitation methods, by
> default, to the visitor that it decorates, you should be able to
> specialize it to add the visitation methods that you need for your
> specialized OCLExpressions. At least, that is how it is intended to
> work ... :-)
>
Thanks! I overlooked that *Decorator when trying to hack my way through
to the EvaluationVisitor. Indeed, extending it and delegating to the
default is enough for me to avoid the "discouraged access" warnings I
had when extending EvaluationVisitorImpl. I think this decorator
approach will be enough to evaluate our expressions.
>
>> Obviously, this is only the way *I* understood the implementation, I
>> could have missed something that would have been much easier to meet my
>> needs. I guess I'll be waiting for your input on this :).
>>
>> Thanks for reading through this.
>>
>> Laurent Goubet
>> Obeo

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

YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyLyI+T2JlbzwvYT4NCmVtYWls O2ludGVybmV0
OmxhdXJlbnQuZ291YmV0QG9iZW8uZnINCnVybDpodHRwOi8vd3d3Lm9iZW8u ZnINCnZlcnNp
b246Mi4xDQplbmQ6dmNhcmQNCg0K
--------------070908070904040605030905--

Re: Custom OCLExpression implementations [message #57528 is a reply to message #57428]

Fri, 30 May 2008 21:51

Eclipse User

Originally posted by: cdamus.zeligsoft.com

--=-nz+Ei9tD11VhxH/WY89S
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi, Laurent,

More comments in-line, below.

Cheers,

Christian

On Fri, 2008-05-30 at 15:15 +0200, laurent Goubet wrote:

> Christian,
>=20
> comments below.
>=20
> Laurent Goubet
> Obeo
>=20
> Christian W. Damus a =C3=A9crit :
> > Hi, Laurent,
> >=20
> > See some replies in-line, below.
> >=20
> > HTH,
> >=20
> > Christian
> >=20
> >=20

-----8<-----

> >> As we cannot instantiate a "T" for the return type, the only solution =
is=20
> >=20
> > What do you mean by "instantiate a 'T'"? The usual substitution for an=
=20
> > evaluation visitor would probably be Object.
> >=20
> I simply meant that there is no way to evaluate the OCLExpression from=20
> "accept" save for delegating to the visitor since we cannot instantiate=20
> Objects of the generic type "T" whatever it is (the compiler wouldn't=20
> accept to cast "Object" to "T" either so we cannot simple return an Objec=
t).

Ah, I think I see. Would the cast to T not simply be an "unchecked
cast" warning? I'm not sure that it should be an error ...

> >
> >> to call one of the parameter visitor's "visitXXX" methods. And here is=
=20
> >> the issue : the "Visitor" interface cannot be overriden by third-party=
=20
> >> plugins, yet it provides no "visitXXX" method for my custom=20
> >> OCLExpression since it doesn't know about it.
> >=20
> > Yes, the Visitor pattern is not known for being friendly to specializat=
ion.
> >=20

-----8<-----

> >=20
> > Have you had a look at the org.eclipse.ocl.EvaluationVisitorDecorator=20
> > class? It is used to hook into the visitXyz() methods of the evaluatio=
n=20
> > visitor. The TracingEvaluationVisitor illustrates how it works, for=20
> > tracing the evaluation of an OCLExpression sub-expression by=20
> > sub-expression (this is used when you enable the "evaluation" tracing=20
> > option at run-time). The EvaluationVisitor ensures that it always=20
> > delegates calls to its decorator if it has one. Because the=20
> > EvaluationVisitorDecorator delegates all of its visitation methods, by=20
> > default, to the visitor that it decorates, you should be able to=20
> > specialize it to add the visitation methods that you need for your=20
> > specialized OCLExpressions. At least, that is how it is intended to=20
> > work ... :-)
> >
> Thanks! I overlooked that *Decorator when trying to hack my way through=20
> to the EvaluationVisitor. Indeed, extending it and delegating to the=20
> default is enough for me to avoid the "discouraged access" warnings I=20
> had when extending EvaluationVisitorImpl. I think this decorator=20
> approach will be enough to evaluate our expressions.

I'm glad that you think so. I hope that your experience may prove
it. ;-)

> >> Obviously, this is only the way *I* understood the implementation, I=20
> >> could have missed something that would have been much easier to meet m=
y=20
> >> needs. I guess I'll be waiting for your input on this :).
> >>
> >> Thanks for reading through this.
> >>
> >> Laurent Goubet
> >> Obeo
>=20

--=-nz+Ei9tD11VhxH/WY89S
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Laurent, 
 
More comments in-line, below. 
 
Cheers, 
 
Christian 
 
On Fri, 2008-05-30 at 15:15 +0200, laurent Goubet wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Christian,

comments below.

Laurent Goubet
Obeo

Christian W. Damus a écrit :
> Hi, Laurent,
> 
> See some replies in-line, below.
> 
> HTH,
> 
> Christian
> 
> 
</PRE>
</BLOCKQUOTE>
-----8<-----
<BLOCKQUOTE TYPE=CITE>
<PRE>
>> As we cannot instantiate a "T" for the return type, the only solution is 
> 
> What do you mean by "instantiate a 'T'"? The usual substitution for an 
> evaluation visitor would probably be Object.
> 
I simply meant that there is no way to evaluate the OCLExpression from 
"accept" save for delegating to the visitor since we cannot instantiate 
Objects of the generic type "T" whatever it is (the compiler wouldn't 
accept to cast "Object" to "T" either so we cannot simple return an Object).
</PRE>
</BLOCKQUOTE>
 
Ah, I think I see.  Would the cast to T not simply be an "unchecked cast" warning?  I'm not sure that it should be an error ... 
 
<BLOCKQUOTE TYPE=CITE>
<PRE>
 >
>> to call one of the parameter visitor's "visitXXX" methods. And here is 
>> the issue : the "Visitor" interface cannot be overriden by third-party 
>> plugins, yet it provides no "visitXXX" method for my custom 
>> OCLExpression since it doesn't know about it.
> 
> Yes, the Visitor pattern is not known for being friendly to specialization.
> 
</PRE>
</BLOCKQUOTE>
-----8<-----
<BLOCKQUOTE TYPE=CITE>
<PRE>
> 
> Have you had a look at the org.eclipse.ocl.EvaluationVisitorDecorator 
> class? It is used to hook into the visitXyz() methods of the evaluation 
> visitor. The TracingEvaluationVisitor illustrates how it works, for 
> tracing the evaluation of an OCLExpression sub-expression by 
> sub-expression (this is used when you enable the "evaluation" tracing 
> option at run-time). The EvaluationVisitor ensures that it always 
> delegates calls to its decorator if it has one. Because the 
> EvaluationVisitorDecorator delegates all of its visitation methods, by 
> default, to the visitor that it decorates, you should be able to 
> specialize it to add the visitation methods that you need for your 
> specialized OCLExpressions. At least, that is how it is intended to 
> work ... :-)
 >
Thanks! I overlooked that *Decorator when trying to hack my way through 
to the EvaluationVisitor. Indeed, extending it and delegating to the 
default is enough for me to avoid the "discouraged access" warnings I 
had when extending EvaluationVisitorImpl. I think this decorator 
approach will be enough to evaluate our expressions.
</PRE>
</BLOCKQUOTE>
 
I'm glad that you think so.  I hope that your experience may prove it.  ;-) 
 
 
<BLOCKQUOTE TYPE=CITE>
<PRE>
>> Obviously, this is only the way *I* understood the implementation, I 
>> could have missed something that would have been much easier to meet my 
>> needs. I guess I'll be waiting for your input on this :).
>>
>> Thanks for reading through this.
>>
>> Laurent Goubet
>> Obeo

</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-nz+Ei9tD11VhxH/WY89S--

Re: Custom OCLExpression implementations [message #57554 is a reply to message #57528]

Mon, 02 June 2008 04:27

Eclipse User

This is a multi-part message in MIME format.
--------------070902000101030301000709
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Christian,

(whoops) indeed, casting to "T" is an unchecked cast warning, not a
compilation error. Doesn't seem to be a good solution to do such things
though ;). I'll try and stick with the decorator as long as it suits my
needs.

Thanks

Laurent Goubet
Obeo

Christian W. Damus a écrit :
> Hi, Laurent,
>
> More comments in-line, below.
>
> Cheers,
>
> Christian
>
> On Fri, 2008-05-30 at 15:15 +0200, laurent Goubet wrote:
>> Christian,
>>
>> comments below.
>>
>> Laurent Goubet
>> Obeo
>>
>> Christian W. Damus a écrit :
>> > Hi, Laurent,
>> >
>> > See some replies in-line, below.
>> >
>> > HTH,
>> >
>> > Christian
>> >
>> >
> -----8<-----
>> >> As we cannot instantiate a "T" for the return type, the only solution is
>> >
>> > What do you mean by "instantiate a 'T'"? The usual substitution for an
>> > evaluation visitor would probably be Object.
>> >
>> I simply meant that there is no way to evaluate the OCLExpression from
>> "accept" save for delegating to the visitor since we cannot instantiate
>> Objects of the generic type "T" whatever it is (the compiler wouldn't
>> accept to cast "Object" to "T" either so we cannot simple return an Object).
>
> Ah, I think I see. Would the cast to T not simply be an "unchecked
> cast" warning? I'm not sure that it should be an error ...
>
>> >
>> >> to call one of the parameter visitor's "visitXXX" methods. And here is
>> >> the issue : the "Visitor" interface cannot be overriden by third-party
>> >> plugins, yet it provides no "visitXXX" method for my custom
>> >> OCLExpression since it doesn't know about it.
>> >
>> > Yes, the Visitor pattern is not known for being friendly to specialization.
>> >
> -----8<-----
>> >
>> > Have you had a look at the org.eclipse.ocl.EvaluationVisitorDecorator
>> > class? It is used to hook into the visitXyz() methods of the evaluation
>> > visitor. The TracingEvaluationVisitor illustrates how it works, for
>> > tracing the evaluation of an OCLExpression sub-expression by
>> > sub-expression (this is used when you enable the "evaluation" tracing
>> > option at run-time). The EvaluationVisitor ensures that it always
>> > delegates calls to its decorator if it has one. Because the
>> > EvaluationVisitorDecorator delegates all of its visitation methods, by
>> > default, to the visitor that it decorates, you should be able to
>> > specialize it to add the visitation methods that you need for your
>> > specialized OCLExpressions. At least, that is how it is intended to
>> > work ... :-)
>> >
>> Thanks! I overlooked that *Decorator when trying to hack my way through
>> to the EvaluationVisitor. Indeed, extending it and delegating to the
>> default is enough for me to avoid the "discouraged access" warnings I
>> had when extending EvaluationVisitorImpl. I think this decorator
>> approach will be enough to evaluate our expressions.
>
> I'm glad that you think so. I hope that your experience may prove it. ;-)
>
>
>> >> Obviously, this is only the way *I* understood the implementation, I
>> >> could have missed something that would have been much easier to meet my
>> >> needs. I guess I'll be waiting for your input on this :).
>> >>
>> >> Thanks for reading through this.
>> >>
>> >> Laurent Goubet
>> >> Obeo
>>

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

YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyLyI+T2JlbzwvYT4NCmVtYWls O2ludGVybmV0
OmxhdXJlbnQuZ291YmV0QG9iZW8uZnINCnVybDpodHRwOi8vd3d3Lm9iZW8u ZnINCnZlcnNp
b246Mi4xDQplbmQ6dmNhcmQNCg0K
--------------070902000101030301000709--

Previous Topic:	Can OCL be used standalone?
Next Topic:	Re: Is it possible to alias types

Goto Forum:

-=] Back to Top [=-

Current Time: Fri Oct 31 06:52:29 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter