Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Custom OCLExpression implementations
Custom OCLExpression implementations [message #57376] Fri, 30 May 2008 04:49 Go to next message
Laurent Goubet is currently offline Laurent Goubet
Messages: 1609
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
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,<BR>
<BR>
See some replies in-line, below.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
<BR>
On Fri, 2008-05-30 at 10:49 +0200, laurent Goubet wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Hi Christian,</FONT>

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

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

<FONT COLOR="#000000">This &quot;Template&quot; class implements org.eclipse.ocl.ecore.OCLExpression so </FONT>
<FONT COLOR="#000000">we were hoping the evaluation would come easily through code such as</FONT>

<FONT COLOR="#000000">OCL&lt;?, EClassifier, ?, ?, ?, ?, ?, ?, ?, Constraint, EClass, EObject&gt; </FONT>
<FONT COLOR="#000000">ocl = OCL.newInstance(EcoreEnvironmentFactory.INSTANCE);</FONT>
<FONT COLOR="#000000">Query&lt;?, ?, ?&gt; query = ocl.createQuery(template);</FONT>
<FONT COLOR="#000000">query.evaluate();</FONT>

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

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

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

</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Yet again this approach doesn't fully satisfies me since I need to </FONT>
<FONT COLOR="#000000">*fully* reimplement a visitor for *all* OCLExpressions and this isn't </FONT>
<FONT COLOR="#000000">possible for the average human (just look at that </FONT>
<FONT COLOR="#000000">&quot;visitOperationCallExp()&quot;!! I can't imagine the headaches you had </FONT>
</PRE>
</BLOCKQUOTE>
<BR>
Heh heh ... I didn't implement this.&nbsp; That visitor was implemented before the OCL interpreter came to me, as long as six years ago.&nbsp; It works, and I haven't yet had a compelling reason to reorganize it.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">implementing this). Couldn't you open the implementation of </FONT>
<FONT COLOR="#000000">org.eclipse.ocl.internal.evaluation.EvaluationVisitorImpl so that a </FONT>
<FONT COLOR="#000000">third-party plugin can add its own logic to evaluate expressions?</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
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).<BR>
<BR>
Have you had a look at the org.eclipse.ocl.EvaluationVisitorDecorator class?&nbsp; It is used to hook into the visitXyz() methods of the evaluation visitor.&nbsp; 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 &quot;evaluation&quot; tracing option at run-time).&nbsp; The EvaluationVisitor ensures that it always delegates calls to its decorator if it has one.&nbsp; 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.&nbsp; At least, that is how it is intended to work&nbsp; ... :-)<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Obviously, this is only the way *I* understood the implementation, I </FONT>
<FONT COLOR="#000000">could have missed something that would have been much easier to meet my </FONT>
<FONT COLOR="#000000">needs. I guess I'll be waiting for your input on this :).</FONT>

<FONT COLOR="#000000">Thanks for reading through this.</FONT>

<FONT COLOR="#000000">Laurent Goubet</FONT>
<FONT COLOR="#000000">Obeo</FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-Q6L6hCcJNMPoPzg1JXP2--
Re: Custom OCLExpression implementations [message #57428 is a reply to message #57402] Fri, 30 May 2008 09:15 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent Goubet
Messages: 1609
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
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,<BR>
<BR>
More comments in-line, below.<BR>
<BR>
Cheers,<BR>
<BR>
Christian<BR>
<BR>
On Fri, 2008-05-30 at 15:15 +0200, laurent Goubet wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Christian,</FONT>

<FONT COLOR="#000000">comments below.</FONT>

<FONT COLOR="#000000">Laurent Goubet</FONT>
<FONT COLOR="#000000">Obeo</FONT>

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

</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 Go to previous message
Laurent Goubet is currently offline Laurent Goubet
Messages: 1609
Registered: July 2009
Senior Member
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:
  


Current Time: Fri Apr 18 04:06:40 EDT 2014

Powered by FUDForum. Page generated in 0.02110 seconds