Home » Modeling » OCL » Metamodel-specific bindings for expressions package ?
|
| Re: Metamodel-specific bindings for expressions package ? [message #15193 is a reply to message #15159] |
Wed, 28 March 2007 12:58   |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Radek,
Sorry for the inconvenience at this late stage. As discussed in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=175446, the original M5
design was only half done. The Types package required mixing in the
Classifier metaclasses from the target metamodel, so that the types would
be compatible with that metamodel. The oversight at the time was that
languages such as QVT needed the same treatment of the OCLExpression,
Variable, etc. that are TypedElements. The different target metamodels
have their own definitions of "typed element": TypedElement in UML,
ETypedElement in Ecore, TypedElement in EMOF.
So, basically, a half-baked cake is now fully baked.
If you're working with EMOF, then you already had to deal with the fact that
EssentialOCL uses EMOF Type in place of UML Classifier. I'm surprised that
you didn't run into the same problem with TypedElement that Ed had in bug
175446. I should have realized sooner that you might be doing similar
things as Ed, and added you to the cc.
I wish I had the time to implement a generator for these bindings, but I
just don't ...
Cheers,
Christian
Radek Dvorak wrote:
> Hello,
>
> I have just updated to the current CVS state of MDT OCL and found
> significant design changes.
>
> I have been implementing EMOF based OCL Environment along with QVT StdLib
> extensions.
> Well, coding against generics with many parameters takes some effort ;-)
> but so far I can confirm that it works as designed.
>
> However, with the latest changes, I am asked to create complete OCL AST
> with metamodel specific bindings.
> Perhaps, I do not have a thorough understanding of the whole motivation
> for this step
> but at least it's clear to me that specific metamodel bindings cost much
> more now.
>
> Somehow could not capture what more I get by this design change.
> Could anyone please help me to understand what I miss?
>
> Regards,
> /Radek
>
|
|
|
| Re: Metamodel-specific bindings for expressions package ? [message #15357 is a reply to message #15193] |
Thu, 29 March 2007 13:11 |
 Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Thanks a lot for your explanation, I am pretty fine with that.
Your fully baked cake tastes well now and we as spoiled customers would =
=
like to get
some extra nuts on it ;)
When trying to implement QVT Stdlib predefined types, I face a problem w=
ith
'List', 'Dictionary' types which extend OCL CollectionType.
As for conformance to CollectionType, it can be realized with the curren=
t =
implementation,
even though there is no clear contract for it. A subtype of the =
CollectionType
having its kind =3D=3D collection is processed as a legal collection and=
it simply seems working fine.
/* Of course, a clear contract for such extensions would be ideal ;) */
The only issue seems to be resolution of generic types on collections,
as the implementation resolves them in a kind of hardcoded way.
This is pretty OK for the OCL stdlib itself, but makes difficulties for =
QVT
StdLib::Dictionary type, which is also a parameterized type but coming =
with yet another
parameter 'keyT' (a HashMap like key type).
A general mechanism to resolve any generic types defined by a custom
environment would help here.
Hoping a better chance for pushing this idea would be submitting a patch=
trying to address the problem, I have written couple of lines, which do =
=
the job
involving the TypeResolver. At least, it makes MDT OCL and my own =
unittests happy.
Would you mind if I raise a bugzilla for you to review the patch?
If feasible, it would be very useful for the QVT component to get =
something like this in M6.
Thanks & Regards,
/Radek
On Wed, 28 Mar 2007 14:58:00 +0200, Christian W. Damus <cdamus@ca.ibm.co=
m> =
wrote:
>
> Hi, Radek,
>
> Sorry for the inconvenience at this late stage. As discussed in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D175446, the original M=
5
> design was only half done. The Types package required mixing in the
> Classifier metaclasses from the target metamodel, so that the types wo=
uld
> be compatible with that metamodel. The oversight at the time was that=
> languages such as QVT needed the same treatment of the OCLExpression,
> Variable, etc. that are TypedElements. The different target metamodel=
s
> have their own definitions of "typed element": TypedElement in UML,
> ETypedElement in Ecore, TypedElement in EMOF.
>
> So, basically, a half-baked cake is now fully baked.
>
> If you're working with EMOF, then you already had to deal with the fac=
t =
> that
> EssentialOCL uses EMOF Type in place of UML Classifier. I'm surprised=
=
> that
> you didn't run into the same problem with TypedElement that Ed had in =
bug
> 175446. I should have realized sooner that you might be doing similar=
> things as Ed, and added you to the cc.
>
> I wish I had the time to implement a generator for these bindings, but=
I
> just don't ...
>
> Cheers,
>
> Christian
>
>
> Radek Dvorak wrote:
>
>> Hello,
>>
>> I have just updated to the current CVS state of MDT OCL and found
>> significant design changes.
>>
>> I have been implementing EMOF based OCL Environment along with QVT =
>> StdLib
>> extensions.
>> Well, coding against generics with many parameters takes some effort =
;-)
>> but so far I can confirm that it works as designed.
>>
>> However, with the latest changes, I am asked to create complete OCL A=
ST
>> with metamodel specific bindings.
>> Perhaps, I do not have a thorough understanding of the whole motivati=
on
>> for this step
>> but at least it's clear to me that specific metamodel bindings cost m=
uch
>> more now.
>>
>> Somehow could not capture what more I get by this design change.
>> Could anyone please help me to understand what I miss?
>>
>> Regards,
>> /Radek
>>
>
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: Metamodel-specific bindings for expressions package ? [message #15390 is a reply to message #15357] |
Thu, 29 March 2007 13:29 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Radek,
See some replies, in-line, below.
Thanks,
Christian
Radek Dvorak wrote:
> Hi Christian,
>
> Thanks a lot for your explanation, I am pretty fine with that.
> Your fully baked cake tastes well now and we as spoiled customers would
> like to get
> some extra nuts on it ;)
Of course! I'm here to serve, as always, inasmuch as I have the resources.
> When trying to implement QVT Stdlib predefined types, I face a problem
> with 'List', 'Dictionary' types which extend OCL CollectionType.
>
> As for conformance to CollectionType, it can be realized with the current
> implementation,
> even though there is no clear contract for it. A subtype of the
> CollectionType
> having its kind == collection is processed as a legal collection and
> it simply seems working fine.
> /* Of course, a clear contract for such extensions would be ideal ;) */
Yes. I had to retain the CollectionKind::Collection literal (despite it not
appearing in the OCL spec) because, otherwise, type declarations such as
Collection(Foo) which are prescribed by the spec would not be possible.
> The only issue seems to be resolution of generic types on collections,
> as the implementation resolves them in a kind of hardcoded way.
> This is pretty OK for the OCL stdlib itself, but makes difficulties for
> QVT StdLib::Dictionary type, which is also a parameterized type but coming
> with yet another
> parameter 'keyT' (a HashMap like key type).
Ah, yes. The TypeResolver, naturally, was only thinking about the kinds of
classifiers that it knows about. :-)
> A general mechanism to resolve any generic types defined by a custom
> environment would help here.
> Hoping a better chance for pushing this idea would be submitting a patch
> trying to address the problem, I have written couple of lines, which do
> the job
> involving the TypeResolver. At least, it makes MDT OCL and my own
> unittests happy.
>
> Would you mind if I raise a bugzilla for you to review the patch?
>
> If feasible, it would be very useful for the QVT component to get
> something like this in M6.
Yes, of course. Please do submit a bugzilla. The problem is, that M6 is
upon us (OCL is scheduled for tomorrow, 30 March). I've had a pretty rough
week just getting the broken binding story fixed, which was a big slap of
new API. I'm not sure I have the stomach for another change this late ...
plus, depending on the size, if legal review by EMO is required, then there
wouldn't even be enough time left in M6. Would this patch require changes
to existing API or only new (optional) API? Is this something that GMF
needs, or only your new QVT component? If the latter, perhaps working it
in early in 1.2 is good for you?
In any case, raise the bug with a patch, and I'll have a look at it.
On a similar note, have you reviewed or even successfully used Ed Willink's
patch for extensibility of the LPG parser? This is something that I would
like to work on early in the next release.
>
>
> Thanks & Regards,
> /Radek
>
<snip>
|
|
|
| Re: Metamodel-specific bindings for expressions package ? [message #15423 is a reply to message #15390] |
Thu, 29 March 2007 14:35 |
Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
I have submitted the patch. I tried to cause minimal changes.
Actually it changes the TypeResolver API by adding 2 operations
but AbstractTypeResolver which the client is encouraged to use provides
the default impl, so no compilation erros should appear.
Yes, I can imagine the rough week when seeing the activity in CVS.
This change is intended only for QVT component.
If not applicable, we can have QVT without these writeable types support=
..
I just had the idea that you can check how serious changes it involves a=
nd
tried to prepare it to make it easier (with respect to M6).
I have not looked yet too deeply into Ed Willink's patch for =
extensibility yet.
Basically it reflects what we need; generate our custom parser based on =
=
your OCL grammer
and extend it with QVT stuff.
Right, this imposes some deps on OCL internal packages of CST, which wou=
ld =
be nice
without "discouraged access" warns (or an API later on).
I will look into this more deeply
We also need to reuse the AST builder, IOW having the OCLParser accessib=
le.
Perhaps, It's too early to know how to make it an API, but can be done =
later,
when we get a better knowledge of what's needed.
Another enhancement would be an AST ValidationVisitor cabable of =
cummulative error diagnostics.
As for the validator, I think we could contribute in case you run out of=
=
resources.
/Radek
On Thu, 29 Mar 2007 15:29:13 +0200, Christian W. Damus <cdamus@ca.ibm.co=
m> =
wrote:
>
> Hi, Radek,
>
> See some replies, in-line, below.
>
> Thanks,
>
> Christian
>
>
> Radek Dvorak wrote:
>
>> Hi Christian,
>>
>> Thanks a lot for your explanation, I am pretty fine with that.
>> Your fully baked cake tastes well now and we as spoiled customers wou=
ld
>> like to get
>> some extra nuts on it ;)
>
> Of course! I'm here to serve, as always, inasmuch as I have the =
> resources.
>
>
>> When trying to implement QVT Stdlib predefined types, I face a proble=
m
>> with 'List', 'Dictionary' types which extend OCL CollectionType.
>>
>> As for conformance to CollectionType, it can be realized with the =
>> current
>> implementation,
>> even though there is no clear contract for it. A subtype of the
>> CollectionType
>> having its kind =3D=3D collection is processed as a legal collection =
and
>> it simply seems working fine.
>> /* Of course, a clear contract for such extensions would be ideal ;) =
*/
>
> Yes. I had to retain the CollectionKind::Collection literal (despite =
it =
> not
> appearing in the OCL spec) because, otherwise, type declarations such =
as
> Collection(Foo) which are prescribed by the spec would not be possible=
..
>
>
>> The only issue seems to be resolution of generic types on collections=
,
>> as the implementation resolves them in a kind of hardcoded way.
>> This is pretty OK for the OCL stdlib itself, but makes difficulties f=
or
>> QVT StdLib::Dictionary type, which is also a parameterized type but =
>> coming
>> with yet another
>> parameter 'keyT' (a HashMap like key type).
>
> Ah, yes. The TypeResolver, naturally, was only thinking about the kin=
ds =
> of
> classifiers that it knows about. :-)
>
>
>> A general mechanism to resolve any generic types defined by a custom
>> environment would help here.
>> Hoping a better chance for pushing this idea would be submitting a pa=
tch
>> trying to address the problem, I have written couple of lines, which =
do
>> the job
>> involving the TypeResolver. At least, it makes MDT OCL and my own
>> unittests happy.
>>
>> Would you mind if I raise a bugzilla for you to review the patch?
>>
>> If feasible, it would be very useful for the QVT component to get
>> something like this in M6.
>
> Yes, of course. Please do submit a bugzilla. The problem is, that M6=
is
> upon us (OCL is scheduled for tomorrow, 30 March). I've had a pretty =
=
> rough
> week just getting the broken binding story fixed, which was a big slap=
of
> new API. I'm not sure I have the stomach for another change this late=
=
> ...
> plus, depending on the size, if legal review by EMO is required, then =
=
> there
> wouldn't even be enough time left in M6. Would this patch require =
> changes
> to existing API or only new (optional) API? Is this something that GM=
F
> needs, or only your new QVT component? If the latter, perhaps working=
it
> in early in 1.2 is good for you?
>
> In any case, raise the bug with a patch, and I'll have a look at it.
>
> On a similar note, have you reviewed or even successfully used Ed =
> Willink's
> patch for extensibility of the LPG parser? This is something that I =
> would
> like to work on early in the next release.
>
>>
>>
>> Thanks & Regards,
>> /Radek
>>
>
> <snip>
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: Metamodel-specific bindings for expressions package ? [message #15455 is a reply to message #15423] |
Thu, 29 March 2007 15:20 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Radek,
Thanks for the patch. The changes looks good to me, but I wouldn't be able
to commit anything without testing it. The compatibility tests
(org.eclipse.emf.ocl.tests) have failures (I had to implement those two new
methods in the CompatibilityEnvironment, but I don't know what I did
wrong). I would also need new JUnits to cover the new behaviour (emulating
the QVT scenario), and of course, I don't have a client application with
which to do ad hoc/regression testing.
Given that this is easily (I think) accommodated, in an API compatible way,
early in OCL 1.2 (by defining these new resolve operations on an
OperationResolver or some such interface extending TypeResolver), I would
be more comfortable waiting for the first 1.2 milestone.
I only did the recent changes for the expressions binding because I realized
that the design was half complete and would have been very difficult to fix
without breaking API compatibility. As it is, the only serious API
breakage is in serialization, for clients that create custom environment
variables etc., now that the generic expression objects (such as Variables)
don't persist their type references. Persistence of OCL constraints now
requires use of the metamodel binding packages for everything. Your
enhancement has no impact on serialization and is easily accommodated in an
API-compatible way, later.
What do you think?
Cheers,
Christian
Radek Dvorak wrote:
>
> I have submitted the patch. I tried to cause minimal changes.
> Actually it changes the TypeResolver API by adding 2 operations
> but AbstractTypeResolver which the client is encouraged to use provides
> the default impl, so no compilation erros should appear.
>
> Yes, I can imagine the rough week when seeing the activity in CVS.
> This change is intended only for QVT component.
> If not applicable, we can have QVT without these writeable types support.
> I just had the idea that you can check how serious changes it involves and
> tried to prepare it to make it easier (with respect to M6).
>
> I have not looked yet too deeply into Ed Willink's patch for
> extensibility yet.
> Basically it reflects what we need; generate our custom parser based on
> your OCL grammer
> and extend it with QVT stuff.
> Right, this imposes some deps on OCL internal packages of CST, which would
> be nice
> without "discouraged access" warns (or an API later on).
> I will look into this more deeply
>
> We also need to reuse the AST builder, IOW having the OCLParser
> accessible. Perhaps, It's too early to know how to make it an API, but can
> be done later,
> when we get a better knowledge of what's needed.
> Another enhancement would be an AST ValidationVisitor cabable of
> cummulative error diagnostics.
> As for the validator, I think we could contribute in case you run out of
> resources.
>
> /Radek
>
<snip>
|
|
|
| Re: Metamodel-specific bindings for expressions package ? [message #15485 is a reply to message #15455] |
Thu, 29 March 2007 16:27 |
Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
I was not aware of the impact on 'org.eclipse.emf.ocl'.
I could have checked it too and figure out what is wrong.
I verified only 'org.eclipse.ocl.uml.tests', 'org.eclipse.ocl.ecore.tests'.
Unfortunately, I also don't have easily separable unittests for this patch;
to be pasted into MDT OCL.
So it's not a good time for this change and I don't want to
push you into another tough day just before M6, with the risk of
finding later that the solution is not 100%.
Initially, I just thought that in case it's a piece of cake for you,
we would get it before the API freeze.
Your suggestion sounds fine. What's the time frame for early OCL 1.2?
Thanks,
/Radek
On Thu, 29 Mar 2007 17:20:59 +0200, Christian W. Damus <cdamus@ca.ibm.com>
wrote:
>
> Hi, Radek,
>
> Thanks for the patch. The changes looks good to me, but I wouldn't be
> able
> to commit anything without testing it. The compatibility tests
> (org.eclipse.emf.ocl.tests) have failures (I had to implement those two
> new
> methods in the CompatibilityEnvironment, but I don't know what I did
> wrong). I would also need new JUnits to cover the new behaviour
> (emulating
> the QVT scenario), and of course, I don't have a client application with
> which to do ad hoc/regression testing.
>
> Given that this is easily (I think) accommodated, in an API compatible
> way,
> early in OCL 1.2 (by defining these new resolve operations on an
> OperationResolver or some such interface extending TypeResolver), I would
> be more comfortable waiting for the first 1.2 milestone.
>
> I only did the recent changes for the expressions binding because I
> realized
> that the design was half complete and would have been very difficult to
> fix
> without breaking API compatibility. As it is, the only serious API
> breakage is in serialization, for clients that create custom environment
> variables etc., now that the generic expression objects (such as
> Variables)
> don't persist their type references. Persistence of OCL constraints now
> requires use of the metamodel binding packages for everything. Your
> enhancement has no impact on serialization and is easily accommodated in
> an
> API-compatible way, later.
>
> What do you think?
>
> Cheers,
>
> Christian
>
>
> Radek Dvorak wrote:
>
>>
>> I have submitted the patch. I tried to cause minimal changes.
>> Actually it changes the TypeResolver API by adding 2 operations
>> but AbstractTypeResolver which the client is encouraged to use provides
>> the default impl, so no compilation erros should appear.
>>
>> Yes, I can imagine the rough week when seeing the activity in CVS.
>> This change is intended only for QVT component.
>> If not applicable, we can have QVT without these writeable types
>> support.
>> I just had the idea that you can check how serious changes it involves
>> and
>> tried to prepare it to make it easier (with respect to M6).
>>
>> I have not looked yet too deeply into Ed Willink's patch for
>> extensibility yet.
>> Basically it reflects what we need; generate our custom parser based on
>> your OCL grammer
>> and extend it with QVT stuff.
>> Right, this imposes some deps on OCL internal packages of CST, which
>> would
>> be nice
>> without "discouraged access" warns (or an API later on).
>> I will look into this more deeply
>>
>> We also need to reuse the AST builder, IOW having the OCLParser
>> accessible. Perhaps, It's too early to know how to make it an API, but
>> can
>> be done later,
>> when we get a better knowledge of what's needed.
>> Another enhancement would be an AST ValidationVisitor cabable of
>> cummulative error diagnostics.
>> As for the validator, I think we could contribute in case you run out of
>> resources.
>>
>> /Radek
>>
>
> <snip>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: Metamodel-specific bindings for expressions package ? [message #15518 is a reply to message #15485] |
Thu, 29 March 2007 18:16 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Thanks, Radek.
That is a relief. I wish I could have been more helpful; I, too, had
thought it might be a piece of cake. I thought it would be easy to fix up
the org.eclipse.emf.ocl, but I guess there's something I don't understand
about how this new feature is supposed to work. I'm actually glad that you
didn't patch it!
I imagine that 1.2 development can start shortly after the Europa release is
done at the end of June. That's when HEAD comes free for the next release.
This will be an easy bit of work to get out of the way at that time. You
can even contribute JUnits and other goodies, then, too. ;-)
We haven't begun any development plan, yet, for the next MDT release, so I
don't even know when the first milestone might be. The MDT component leads
and Kenn will have to discuss that. Keep your eye on the MDT website for
developments after Europa.
Cheers,
Christian
Radek Dvorak wrote:
> Hi Christian,
>
> I was not aware of the impact on 'org.eclipse.emf.ocl'.
> I could have checked it too and figure out what is wrong.
> I verified only 'org.eclipse.ocl.uml.tests',
> 'org.eclipse.ocl.ecore.tests'. Unfortunately, I also don't have easily
> separable unittests for this patch; to be pasted into MDT OCL.
>
> So it's not a good time for this change and I don't want to
> push you into another tough day just before M6, with the risk of
> finding later that the solution is not 100%.
>
> Initially, I just thought that in case it's a piece of cake for you,
> we would get it before the API freeze.
>
> Your suggestion sounds fine. What's the time frame for early OCL 1.2?
>
> Thanks,
> /Radek
>
<snip>
|
|
|
| Re: Metamodel-specific bindings for expressions package ? [message #15550 is a reply to message #15518] |
Fri, 30 March 2007 16:26 |
Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Could you help me please with that kind of magic you use to
generate the source code from a Metamodel-specific bindings
genmodel like OCLEcore.genmodel, OCLUML.genmodel?
I simply result in java source which contains the type parameter names
like C, PM instead of instantiated types and it obviously can't
compile.
Thanks,
/Radek
On Thu, 29 Mar 2007 20:16:36 +0200, Christian W. Damus <cdamus@ca.ibm.com>
wrote:
>
> Thanks, Radek.
>
> That is a relief. I wish I could have been more helpful; I, too, had
> thought it might be a piece of cake. I thought it would be easy to fix
> up
> the org.eclipse.emf.ocl, but I guess there's something I don't understand
> about how this new feature is supposed to work. I'm actually glad that
> you
> didn't patch it!
>
> I imagine that 1.2 development can start shortly after the Europa
> release is
> done at the end of June. That's when HEAD comes free for the next
> release.
> This will be an easy bit of work to get out of the way at that time. You
> can even contribute JUnits and other goodies, then, too. ;-)
>
> We haven't begun any development plan, yet, for the next MDT release, so
> I
> don't even know when the first milestone might be. The MDT component
> leads
> and Kenn will have to discuss that. Keep your eye on the MDT website for
> developments after Europa.
>
> Cheers,
>
> Christian
>
>
> Radek Dvorak wrote:
>
>> Hi Christian,
>>
>> I was not aware of the impact on 'org.eclipse.emf.ocl'.
>> I could have checked it too and figure out what is wrong.
>> I verified only 'org.eclipse.ocl.uml.tests',
>> 'org.eclipse.ocl.ecore.tests'. Unfortunately, I also don't have easily
>> separable unittests for this patch; to be pasted into MDT OCL.
>>
>> So it's not a good time for this change and I don't want to
>> push you into another tough day just before M6, with the risk of
>> finding later that the solution is not 100%.
>>
>> Initially, I just thought that in case it's a piece of cake for you,
>> we would get it before the API freeze.
>>
>> Your suggestion sounds fine. What's the time frame for early OCL 1.2?
>>
>> Thanks,
>> /Radek
>>
>
> <snip>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: Metamodel-specific bindings for expressions package ? [message #15580 is a reply to message #15550] |
Fri, 30 March 2007 17:26 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Radek,
Unfortunately, there is no magic involved, just Eclipse's wonderful
search-and-replace function to replace type parameter names with their
correct substitutions. At least, that is, until
https://bugs.eclipse.org/bugs/show_bug.cgi?id=167935 is resolved.
Cheers,
Christian
Radek Dvorak wrote:
> Hi Christian,
>
> Could you help me please with that kind of magic you use to
> generate the source code from a Metamodel-specific bindings
> genmodel like OCLEcore.genmodel, OCLUML.genmodel?
>
> I simply result in java source which contains the type parameter names
> like C, PM instead of instantiated types and it obviously can't
> compile.
>
> Thanks,
> /Radek
<snip>
|
|
|
| Re: Metamodel-specific bindings for expressions package ? [message #15612 is a reply to message #15580] |
Fri, 30 March 2007 18:35 |
Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Thanks for info, at least I know I have used the right approach ;)
On Fri, 30 Mar 2007 19:26:24 +0200, Christian W. Damus <cdamus@ca.ibm.co=
m> =
wrote:
>
> Hi, Radek,
>
> Unfortunately, there is no magic involved, just Eclipse's wonderful
> search-and-replace function to replace type parameter names with their=
> correct substitutions. At least, that is, until
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D167935 is resolved.
>
> Cheers,
>
> Christian
>
>
> Radek Dvorak wrote:
>
>> Hi Christian,
>>
>> Could you help me please with that kind of magic you use to
>> generate the source code from a Metamodel-specific bindings
>> genmodel like OCLEcore.genmodel, OCLUML.genmodel?
>>
>> I simply result in java source which contains the type parameter name=
s
>> like C, PM instead of instantiated types and it obviously can't
>> compile.
>>
>> Thanks,
>> /Radek
>
> <snip>
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
| |
| Re: Metamodel-specific bindings for expressions package ? [message #18620 is a reply to message #17362] |
Wed, 18 April 2007 15:49 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Sergey,
See some replies in-line, below.
Cheers,
Christian
sboyko wrote:
> Hello Christian,
>
>
> We've looked into Ed Willink's patch (from #176110). It's satisfy our
> requirements for extensibility both in CST and AST parsers:
> - configurable error handling policies
> - overridable OCLParser::oclExpressionCS() method
> We're expecting that patch is applied to OCL so we can reuse it in our
> Operational QVT implementation.
Good! That's encouraging. I'm planning/hoping to adopt Ed's refactoring in
the next OCL release.
> Also I'm start reusing OCL evaluator as a part or QVT evaluator. Below are
> some qestions (or should I better raise bugzilla ?):
>
> * I think it'll be usefull making AnyType::oclAsType() applicable for
> primitive types.
> For example '10.oclAsType(String)' will result in String type (instead
> of
> Integer type as now).
Well, that wouldn't be a valid usage. oclAsType() performs casts up or down
the inheritance graph. It doesn't perform value conversions of this
nature. String and Integer are unrelated types.
You should use the String toReal() and toInteger() operations to convert
strings to numbers. Unfortunately, the OCL spec forgot the corresponding
Real::toString() operation. :-(
> * shouldn't ocl.util.TypeUtil::matchArgs() perform checking non-null
> 'refferedType' for 'TypeType' arguments ?
Yes, it could, but validation of the OCLExpression should catch the absence
of a referredType. If you're constructing an OCLExpression (rather than
parsing it), then you should validate it before attempting to use it. If
this check is missing from the validation visitor, then that's a bug :-)
> * union() with oclInvalid() leads to ClassCastException in
> EvaluationVisitorImpl:1012
Which should just result in OclInvalid again. Do you get a
ClassCastException from the evaluation? You should just get an OclInvalid
result. In either case, this needs a bugzilla because it would be better
to check for an OclInvalid argument and just return OclInvalid again (other
operation calls already do this).
> * ocl.ecore.internal.UMLReflectionImpl::getOwningClassifier() fails to
> resolve shadow parent of operation
> (meanwhile ocl.ecore.internal.UMLReflectionImpl::getOwner() does).
I think that getOwningClassifier() is meant to get the classifier that
"logically" owns the operation, which in the case of Ecore is the
EDataType, not its shadow EClass. Looks like the Javadoc could use some
fixing.
> * shouldn't operations defined on types like OclAny (actually on shadowed
> OclAny_Class) be resolved
> by Environment.lookupOperation() (called from TypeUtil.getOperations())
> ?
I think so, yes. The OCL spec doesn't discourage the definition of
additional properties and operations on its standard library types. Of
course, they would be stored in an additional shadow class in your
environment, not in the standard library package, itself. I imagine that
you have the same problem with the other standard library types, not just
OclAny?
>
>
> Regards,
> Sergey.
>
>
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote:
>>Hi, Radek,
|
|
|
| Re: Metamodel-specific bindings for expressions package ? [message #18781 is a reply to message #18620] |
Thu, 19 April 2007 09:54 |
Sergey Boyko
Messages: 171
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Thank you for the explanation! Below are some comments.
Wbr,
Sergey.
> >
> > We've looked into Ed Willink's patch (from #176110). It's
> satisfy our
> > requirements for extensibility both in CST and AST parsers:
> > - configurable error handling policies
> > - overridable OCLParser::oclExpressionCS() method We're
> expecting that
> > patch is applied to OCL so we can reuse it in our Operational QVT
> > implementation.
>
> Good! That's encouraging. I'm planning/hoping to adopt Ed's
> refactoring in the next OCL release.
So we can expect patch will be available in M7 milestone ?
> > * shouldn't ocl.util.TypeUtil::matchArgs() perform checking
> non-null
> > 'refferedType' for 'TypeType' arguments ?
>
> Yes, it could, but validation of the OCLExpression should
> catch the absence of a referredType. If you're constructing
> an OCLExpression (rather than parsing it), then you should
> validate it before attempting to use it. If this check is
> missing from the validation visitor, then that's a bug :-)
Aha, I see. Validation visitor do the job :)
> > * union() with oclInvalid() leads to ClassCastException in
> > EvaluationVisitorImpl:1012
>
> Which should just result in OclInvalid again. Do you get a
> ClassCastException from the evaluation? You should just get
> an OclInvalid result. In either case, this needs a bugzilla
> because it would be better to check for an OclInvalid
> argument and just return OclInvalid again (other operation
> calls already do this).
Done. #183144
> ocl.ecore.internal.UMLReflectionImpl::getOwningClassifier() fails to
> > resolve shadow parent of operation
> > (meanwhile ocl.ecore.internal.UMLReflectionImpl::getOwner() does).
>
> I think that getOwningClassifier() is meant to get the
> classifier that "logically" owns the operation, which in the
> case of Ecore is the EDataType, not its shadow EClass. Looks
> like the Javadoc could use some fixing.
>
I didn't clearly specify the case.
For the addition operations defined say on OclAny their real parent is
OclAny_Class. And getOwningClassifier() returns just it while OclAny is
expected.
On the other hand OCLStandardLibraryImpl::getOwner() returns correct parent
for such operation.
The question was that getOwningClassifier() should also resolve shadowed
parent like getOwner() does.
> > * shouldn't operations defined on types like OclAny (actually on
> > shadowed
> > OclAny_Class) be resolved
> > by Environment.lookupOperation() (called from
> TypeUtil.getOperations())
> > ?
>
> I think so, yes. The OCL spec doesn't discourage the
> definition of additional properties and operations on its
> standard library types. Of course, they would be stored in
> an additional shadow class in your environment, not in the
> standard library package, itself. I imagine that you have
> the same problem with the other standard library types, not
> just OclAny?
Yes, same problems with all types from OCLStdLib. OclAny was taken as an
example.
> >
> >
> > Regards,
> > Sergey.
|
|
|
| Re: Metamodel-specific bindings for expressions package ? [message #18849 is a reply to message #18781] |
Thu, 19 April 2007 13:12 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Sergey,
More replies in-line, below ...
Thanks,
Christian
Sergey Boyko wrote:
> Hi Christian,
>
> Thank you for the explanation! Below are some comments.
>
> Wbr,
> Sergey.
>
>> >
>> > We've looked into Ed Willink's patch (from #176110). It's
>> satisfy our
>> > requirements for extensibility both in CST and AST parsers:
>> > - configurable error handling policies
>> > - overridable OCLParser::oclExpressionCS() method We're
>> expecting that
>> > patch is applied to OCL so we can reuse it in our Operational QVT
>> > implementation.
>>
>> Good! That's encouraging. I'm planning/hoping to adopt Ed's
>> refactoring in the next OCL release.
>
> So we can expect patch will be available in M7 milestone ?
No. I mean the next *release*, not milestone. This scale of contribution
will have to go through the foundation's legal review process, for which
the Europa deadline is long past.
>> > * shouldn't ocl.util.TypeUtil::matchArgs() perform checking
>> non-null
>> > 'refferedType' for 'TypeType' arguments ?
>>
>> Yes, it could, but validation of the OCLExpression should
>> catch the absence of a referredType. If you're constructing
>> an OCLExpression (rather than parsing it), then you should
>> validate it before attempting to use it. If this check is
>> missing from the validation visitor, then that's a bug :-)
>
> Aha, I see. Validation visitor do the job :)
>
>> > * union() with oclInvalid() leads to ClassCastException in
>> > EvaluationVisitorImpl:1012
>>
>> Which should just result in OclInvalid again. Do you get a
>> ClassCastException from the evaluation? You should just get
>> an OclInvalid result. In either case, this needs a bugzilla
>> because it would be better to check for an OclInvalid
>> argument and just return OclInvalid again (other operation
>> calls already do this).
>
> Done. #183144
Thanks! I saw it already.
>> ocl.ecore.internal.UMLReflectionImpl::getOwningClassifier() fails to
>> > resolve shadow parent of operation
>> > (meanwhile ocl.ecore.internal.UMLReflectionImpl::getOwner() does).
>>
>> I think that getOwningClassifier() is meant to get the
>> classifier that "logically" owns the operation, which in the
>> case of Ecore is the EDataType, not its shadow EClass. Looks
>> like the Javadoc could use some fixing.
>>
>
> I didn't clearly specify the case.
> For the addition operations defined say on OclAny their real parent is
> OclAny_Class. And getOwningClassifier() returns just it while OclAny is
> expected.
> On the other hand OCLStandardLibraryImpl::getOwner() returns correct
> parent for such operation.
> The question was that getOwningClassifier() should also resolve shadowed
> parent like getOwner() does.
On a closer look at the usage of getOwningClassifer() within the OCL
component, I see that it is expected to return the "logical" owner, which
is a shadowed classifier if necessary. So, you are right, it should do the
same as OCLStandardLibraryImpl::getOwner. Looks like a bug!
>> > * shouldn't operations defined on types like OclAny (actually on
>> > shadowed
>> > OclAny_Class) be resolved
>> > by Environment.lookupOperation() (called from
>> TypeUtil.getOperations())
>> > ?
>>
>> I think so, yes. The OCL spec doesn't discourage the
>> definition of additional properties and operations on its
>> standard library types. Of course, they would be stored in
>> an additional shadow class in your environment, not in the
>> standard library package, itself. I imagine that you have
>> the same problem with the other standard library types, not
>> just OclAny?
>
> Yes, same problems with all types from OCLStdLib. OclAny was taken as an
> example.
Right, that's what I figured. Looks like a bugzilla, then, but I don't know
that I can promise it for M7/1.1. I'm not sure about how to deal with the
dual shadows for Ecore, or how best to go about it ...
>> >
>> >
>> > Regards,
>> > Sergey.
|
|
|
| Re: Metamodel-specific bindings for expressions package ? [message #19514 is a reply to message #18849] |
Mon, 23 April 2007 14:07 |
Sergey Boyko
Messages: 171
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Comments are in-lined below..
Best Regards,
Sergey.
> >> > We've looked into Ed Willink's patch (from #176110). It's
> >> satisfy our
> >> > requirements for extensibility both in CST and AST parsers:
> >> > - configurable error handling policies
> >> > - overridable OCLParser::oclExpressionCS() method We're
> >> expecting that
> >> > patch is applied to OCL so we can reuse it in our
> Operational QVT
> >> > implementation.
> >>
> >> Good! That's encouraging. I'm planning/hoping to adopt Ed's
> >> refactoring in the next OCL release.
> >
> > So we can expect patch will be available in M7 milestone ?
>
> No. I mean the next *release*, not milestone. This scale of
> contribution will have to go through the foundation's legal
> review process, for which the Europa deadline is long past.
Ok, I see.
There is some change I need to be applied to OCLParser. Could you please
change 'protected final OCLExpression<C> oclExpressionCS(..)' to be non-final.
Otherwise I'm unable to build QVT parser on top of OCL one.
> >
> > I didn't clearly specify the case.
> > For the addition operations defined say on OclAny their
> real parent is
> > OclAny_Class. And getOwningClassifier() returns just it
> while OclAny
> > is expected.
> > On the other hand OCLStandardLibraryImpl::getOwner()
> returns correct
> > parent for such operation.
> > The question was that getOwningClassifier() should also resolve
> > shadowed parent like getOwner() does.
>
> On a closer look at the usage of getOwningClassifer() within
> the OCL component, I see that it is expected to return the
> "logical" owner, which is a shadowed classifier if necessary.
> So, you are right, it should do the same as
> OCLStandardLibraryImpl::getOwner. Looks like a bug!
Then I'll submit bugzilla for it.
>
> >> > * shouldn't operations defined on types like OclAny (actually on
> >> > shadowed
> >> > OclAny_Class) be resolved
> >> > by Environment.lookupOperation() (called from
> >> TypeUtil.getOperations())
> >> > ?
> >>
> >> I think so, yes. The OCL spec doesn't discourage the
> definition of
> >> additional properties and operations on its standard
> library types.
> >> Of course, they would be stored in an additional shadow
> class in your
> >> environment, not in the standard library package, itself.
> I imagine
> >> that you have the same problem with the other standard
> library types,
> >> not just OclAny?
> >
> > Yes, same problems with all types from OCLStdLib. OclAny
> was taken as
> > an example.
>
> Right, that's what I figured. Looks like a bugzilla, then,
> but I don't know that I can promise it for M7/1.1. I'm not
> sure about how to deal with the dual shadows for Ecore, or
> how best to go about it ...
It's not significant issue. I'll submit bug for it just to for the record.
> >> >
> >> >
> >> > Regards,
> >> > Sergey.
|
|
|
| Re: Metamodel-specific bindings for expressions package ? [message #19649 is a reply to message #19514] |
Mon, 23 April 2007 17:15 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Sergey,
When are you planning to deliver your QVT implementation? Do you need a
change such as un-finalizing the oclExpressionCS operation in the 1.1
release, in particular?
In any case, you'll want to raise an enhancement request for that in
bugzilla, and we'll take it from there.
Thanks,
Christian
Sergey Boyko wrote:
> Hi Christian,
>
> Comments are in-lined below..
>
> Best Regards,
> Sergey.
>
>
>> >> > We've looked into Ed Willink's patch (from #176110). It's
>> >> satisfy our
>> >> > requirements for extensibility both in CST and AST parsers:
>> >> > - configurable error handling policies
>> >> > - overridable OCLParser::oclExpressionCS() method We're
>> >> expecting that
>> >> > patch is applied to OCL so we can reuse it in our
>> Operational QVT
>> >> > implementation.
>> >>
>> >> Good! That's encouraging. I'm planning/hoping to adopt Ed's
>> >> refactoring in the next OCL release.
>> >
>> > So we can expect patch will be available in M7 milestone ?
>>
>> No. I mean the next *release*, not milestone. This scale of
>> contribution will have to go through the foundation's legal
>> review process, for which the Europa deadline is long past.
>
> Ok, I see.
> There is some change I need to be applied to OCLParser. Could you please
> change 'protected final OCLExpression<C> oclExpressionCS(..)' to be
> non-final. Otherwise I'm unable to build QVT parser on top of OCL one.
>
<snip>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 01:37:24 GMT 2024
Powered by FUDForum. Page generated in 0.04136 seconds |
] 
Search
Help
Register
Login
Home
