Home » Modeling » OCL » OCL type checking
| OCL type checking [message #70497] |
Thu, 07 May 2009 12:50  |
|
This is a multi-part message in MIME format.
--------------060801010002030201060707
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
I recently looked at the changes introduced in OCL with the inclusion of
the TypeChecker interface ( through bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=233673 ).
This gives third-party plugins a great deal of capabilities in dynamic
typing of custom operations and the such, yet I think some of the
standard operations could also benefit from this. The most obvious
example I have in mind would be something like this :
"randomList->select(oclIsKindOf(Type))"
At current, a user doing such a select operation will need to cast the
result in order to use its specific operations. Consider something like
this :
"randomList-> select(oclIsKindOf(ENamedElement)).oclAsType(ENamedElement). name "
I know there are way more complicated things than this that can happen
in an iterate; but at least those cases are obvious... and pretty
frequent. If I am not mistaken, the impossibility to type the result of
a select comes from line 3709 of AbstractOCLAnalyzer :
3708 } else if (name.equals("select") || name.equals("reject"))
{//$NON-NLS-2$//$NON-NLS-1$
3709 astNode.setType(source.getType());
Would there be any way to leverage the new TypeChecker in such cases or
was that a deliberate overlook?
Regards,
Laurent Goubet
Obeo
--------------060801010002030201060707
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
--------------060801010002030201060707--
|
|
|
| Re: OCL type checking [message #70559 is a reply to message #70497] |
Thu, 07 May 2009 13:15  |
|
--=-umL2vLUXNSDqBSTH3CCk
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Laurent,
If I'm not mistaken, there was some discussion of this in the context of
QVT's need to modify the semantics of the OCL library. But, I think
those changes are incompatible from an API contract perspective, so they
were taken back to OMG as spec issues.
Unfortunately, changing the result type of a standard library operation
would be quite a deviation from the spec. It would be much nicer to be
able to define, in OCL or Java, a "typeSelect" operation for collections
(a la Xtend/Xpand). That isn't possible currently, as the specification
of type arguments in oclAsType (and consequently an hypothetical
typeSelect) is flawed. The changes already adopted by OMG for the OCL
2.1 revision should address that problem (specifically, doing away with
TypeType metaclass and OclType, using the Classifier metaclass instead).
Cheers,
Christian
On Thu, 2009-05-07 at 14:50 +0200, laurent Goubet wrote:
> Hi,
>
> I recently looked at the changes introduced in OCL with the inclusion of
> the TypeChecker interface ( through bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=233673 ).
>
> This gives third-party plugins a great deal of capabilities in dynamic
> typing of custom operations and the such, yet I think some of the
> standard operations could also benefit from this. The most obvious
> example I have in mind would be something like this :
> "randomList->select(oclIsKindOf(Type))"
>
> At current, a user doing such a select operation will need to cast the
> result in order to use its specific operations. Consider something like
> this :
> "randomList-> select(oclIsKindOf(ENamedElement)).oclAsType(ENamedElement). name "
>
>
> I know there are way more complicated things than this that can happen
> in an iterate; but at least those cases are obvious... and pretty
> frequent. If I am not mistaken, the impossibility to type the result of
> a select comes from line 3709 of AbstractOCLAnalyzer :
> 3708 } else if (name.equals("select") || name.equals("reject"))
> {//$NON-NLS-2$//$NON-NLS-1$
> 3709 astNode.setType(source.getType());
>
> Would there be any way to leverage the new TypeChecker in such cases or
> was that a deliberate overlook?
>
> Regards,
>
> Laurent Goubet
> Obeo
--=-umL2vLUXNSDqBSTH3CCk
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.24.1.1">
</HEAD>
<BODY>
Hi, Laurent,<BR>
<BR>
If I'm not mistaken, there was some discussion of this in the context of QVT's need to modify the semantics of the OCL library. But, I think those changes are incompatible from an API contract perspective, so they were taken back to OMG as spec issues.<BR>
<BR>
Unfortunately, changing the result type of a standard library operation would be quite a deviation from the spec. It would be much nicer to be able to define, in OCL or Java, a "typeSelect" operation for collections (a la Xtend/Xpand). That isn't possible currently, as the specification of type arguments in oclAsType (and consequently an hypothetical typeSelect) is flawed. The changes already adopted by OMG for the OCL 2.1 revision should address that problem (specifically, doing away with TypeType metaclass and OclType, using the Classifier metaclass instead).<BR>
<BR>
Cheers,<BR>
<BR>
Christian<BR>
<BR>
On Thu, 2009-05-07 at 14:50 +0200, laurent Goubet wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi,
I recently looked at the changes introduced in OCL with the inclusion of
the TypeChecker interface ( through bug
<A HREF="https://bugs.eclipse.org/bugs/show_bug.cgi?id=233673">https://bugs.eclipse.org/bugs/show_bug.cgi?id=233673</A> ).
This gives third-party plugins a great deal of capabilities in dynamic
typing of custom operations and the such, yet I think some of the
standard operations could also benefit from this. The most obvious
example I have in mind would be something like this :
"randomList->select(oclIsKindOf(Type))&q uot;
At current, a user doing such a select operation will need to cast the
result in order to use its specific operations. Consider something like
this :
"randomList->select(oclIsKindOf(ENamedElemen t)).oclAsType(ENamedElement).name"
I know there are way more complicated things than this that can happen
in an iterate; but at least those cases are obvious... and pretty
frequent. If I am not mistaken, the impossibility to type the result of
a select comes from line 3709 of AbstractOCLAnalyzer :
3708 } else if (name.equals("select") || name.equals("reject"))
{//$NON-NLS-2$//$NON-NLS-1$
3709 astNode.setType(source.getType());
Would there be any way to leverage the new TypeChecker in such cases or
was that a deliberate overlook?
Regards,
Laurent Goubet
Obeo
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-umL2vLUXNSDqBSTH3CCk--
|
|
|
| Re: OCL type checking [message #70578 is a reply to message #70559] |
Thu, 07 May 2009 13:28 |
|
This is a multi-part message in MIME format.
--------------030704030602000600090908
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Hi Christian,
Indeed, this can be seen as a deviation from the spec, didn't really
look at it that way :p.
Thanks for the insight.
Laurent Goubet
Obeo
Christian W. Damus a écrit :
> Hi, Laurent,
>
> If I'm not mistaken, there was some discussion of this in the context of
> QVT's need to modify the semantics of the OCL library. But, I think
> those changes are incompatible from an API contract perspective, so they
> were taken back to OMG as spec issues.
>
> Unfortunately, changing the result type of a standard library operation
> would be quite a deviation from the spec. It would be much nicer to be
> able to define, in OCL or Java, a "typeSelect" operation for collections
> (a la Xtend/Xpand). That isn't possible currently, as the specification
> of type arguments in oclAsType (and consequently an hypothetical
> typeSelect) is flawed. The changes already adopted by OMG for the OCL
> 2.1 revision should address that problem (specifically, doing away with
> TypeType metaclass and OclType, using the Classifier metaclass instead).
>
> Cheers,
>
> Christian
>
> On Thu, 2009-05-07 at 14:50 +0200, laurent Goubet wrote:
>> Hi,
>>
>> I recently looked at the changes introduced in OCL with the inclusion of
>> the TypeChecker interface ( through bug
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=233673 ).
>>
>> This gives third-party plugins a great deal of capabilities in dynamic
>> typing of custom operations and the such, yet I think some of the
>> standard operations could also benefit from this. The most obvious
>> example I have in mind would be something like this :
>> "randomList->select(oclIsKindOf(Type))"
>>
>> At current, a user doing such a select operation will need to cast the
>> result in order to use its specific operations. Consider something like
>> this :
>> "randomList-> select(oclIsKindOf(ENamedElement)).oclAsType(ENamedElement). name "
>>
>>
>> I know there are way more complicated things than this that can happen
>> in an iterate; but at least those cases are obvious... and pretty
>> frequent. If I am not mistaken, the impossibility to type the result of
>> a select comes from line 3709 of AbstractOCLAnalyzer :
>> 3708 } else if (name.equals("select") || name.equals("reject"))
>> {//$NON-NLS-2$//$NON-NLS-1$
>> 3709 astNode.setType(source.getType());
>>
>> Would there be any way to leverage the new TypeChecker in such cases or
>> was that a deliberate overlook?
>>
>> Regards,
>>
>> Laurent Goubet
>> Obeo
--------------030704030602000600090908
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
--------------030704030602000600090908--
|
|
|
| Re: OCL type checking [message #70598 is a reply to message #70578] |
Thu, 07 May 2009 13:42 |
|
--=-8jPJ4+XcA8/rwM8OmdDA
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi, Laurent,
On the flip side, sometimes deviation is good because it is practically
useful. :-) Especially with in the case of some specs. :-D
Goodness knows that the MDT OCL implementation already has more than its
share of deviations, some intended and more not. The problem with
deviation from spec is, of course, portability of models to other
implementations. So, it would be more beneficial for everyone to
improve the spec by the addition of capabilities like "typeSelect" but
that is more difficult than just implementing them :-(
cW
On Thu, 2009-05-07 at 15:28 +0200, laurent Goubet wrote:
> Hi Christian,
>=20
> Indeed, this can be seen as a deviation from the spec, didn't really=20
> look at it that way :p.
>=20
> Thanks for the insight.
>=20
> Laurent Goubet
> Obeo
>=20
> Christian W. Damus a =C3=A9crit :
> > Hi, Laurent,
> >=20
> > If I'm not mistaken, there was some discussion of this in the context o=
f=20
> > QVT's need to modify the semantics of the OCL library. But, I think=20
> > those changes are incompatible from an API contract perspective, so the=
y=20
> > were taken back to OMG as spec issues.
> >=20
> > Unfortunately, changing the result type of a standard library operation=
=20
> > would be quite a deviation from the spec. It would be much nicer to be=
=20
> > able to define, in OCL or Java, a "typeSelect" operation for collection=
s=20
> > (a la Xtend/Xpand). That isn't possible currently, as the specificatio=
n=20
> > of type arguments in oclAsType (and consequently an hypothetical=20
> > typeSelect) is flawed. The changes already adopted by OMG for the OCL=20
> > 2.1 revision should address that problem (specifically, doing away with=
=20
> > TypeType metaclass and OclType, using the Classifier metaclass instead)=
..
> >=20
> > Cheers,
> >=20
> > Christian
> >=20
> > On Thu, 2009-05-07 at 14:50 +0200, laurent Goubet wrote:
> >> Hi,
> >>
> >> I recently looked at the changes introduced in OCL with the inclusion =
of=20
> >> the TypeChecker interface ( through bug=20
> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D233673 ).
> >>
> >> This gives third-party plugins a great deal of capabilities in dynamic=
=20
> >> typing of custom operations and the such, yet I think some of the=20
> >> standard operations could also benefit from this. The most obvious=20
> >> example I have in mind would be something like this :
> >> "randomList->select(oclIsKindOf(Type))"
> >>
> >> At current, a user doing such a select operation will need to cast the=
=20
> >> result in order to use its specific operations. Consider something lik=
e=20
> >> this :
> >> "randomList->select(oclIsKindOf(ENamedElement)).oclAsType(ENamedElemen=
t).name"=20
> >>
> >>
> >> I know there are way more complicated things than this that can happen=
=20
> >> in an iterate; but at least those cases are obvious... and pretty=20
> >> frequent. If I am not mistaken, the impossibility to type the result o=
f=20
> >> a select comes from line 3709 of AbstractOCLAnalyzer :
> >> 3708 } else if (name.equals("select") || name.equals("reject"))=20
> >> {//$NON-NLS-2$//$NON-NLS-1$
> >> 3709 astNode.setType(source.getType());
> >>
> >> Would there be any way to leverage the new TypeChecker in such cases o=
r=20
> >> was that a deliberate overlook?
> >>
> >> Regards,
> >>
> >> Laurent Goubet
> >> Obeo
>=20
--=-8jPJ4+XcA8/rwM8OmdDA
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.24.1.1">
</HEAD>
<BODY>
Hi, Laurent,<BR>
<BR>
On the flip side, sometimes deviation is good because it is practically useful. :-) Especially with in the case of some specs. :-D<BR>
<BR>
Goodness knows that the MDT OCL implementation already has more than its share of deviations, some intended and more not. The problem with deviation from spec is, of course, portability of models to other implementations. So, it would be more beneficial for everyone to improve the spec by the addition of capabilities like "typeSelect" but that is more difficult than just implementing them :-(<BR>
<BR>
cW<BR>
<BR>
On Thu, 2009-05-07 at 15:28 +0200, laurent Goubet wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Christian,
Indeed, this can be seen as a deviation from the spec, didn't really
look at it that way :p.
Thanks for the insight.
Laurent Goubet
Obeo
Christian W. Damus a écrit :
> Hi, Laurent,
>
> If I'm not mistaken, there was some discussion of this in the context of
> QVT's need to modify the semantics of the OCL library. But, I think
> those changes are incompatible from an API contract perspective, so they
> were taken back to OMG as spec issues.
>
> Unfortunately, changing the result type of a standard library operation
> would be quite a deviation from the spec. It would be much nicer to be
> able to define, in OCL or Java, a "typeSelect" operation for collections
> (a la Xtend/Xpand). That isn't possible currently, as the specification
> of type arguments in oclAsType (and consequently an hypothetical
> typeSelect) is flawed. The changes already adopted by OMG for the OCL
> 2.1 revision should address that problem (specifically, doing away with
> TypeType metaclass and OclType, using the Classifier metaclass instead).
>
> Cheers,
>
> Christian
>
> On Thu, 2009-05-07 at 14:50 +0200, laurent Goubet wrote:
>> Hi,
>>
>> I recently looked at the changes introduced in OCL with the inclusion of
>> the TypeChecker interface ( through bug
>> <A HREF="https://bugs.eclipse.org/bugs/show_bug.cgi?id=233673">https://bugs.eclipse.org/bugs/show_bug.cgi?id=233673</A> ).
>>
>> This gives third-party plugins a great deal of capabilities in dynamic
>> typing of custom operations and the such, yet I think some of the
>> standard operations could also benefit from this. The most obvious
>> example I have in mind would be something like this :
>> "randomList->select(oclIsKindOf(Type))&q uot;
>>
>> At current, a user doing such a select operation will need to cast the
>> result in order to use its specific operations. Consider something like
>> this :
>> "randomList->select(oclIsKindOf(ENamedElemen t)).oclAsType(ENamedElement).name"
>>
>>
>> I know there are way more complicated things than this that can happen
>> in an iterate; but at least those cases are obvious... and pretty
>> frequent. If I am not mistaken, the impossibility to type the result of
>> a select comes from line 3709 of AbstractOCLAnalyzer :
>> 3708 } else if (name.equals("select") || name.equals("reject"))
>> {//$NON-NLS-2$//$NON-NLS-1$
>> 3709 astNode.setType(source.getType());
>>
>> Would there be any way to leverage the new TypeChecker in such cases or
>> was that a deliberate overlook?
>>
>> Regards,
>>
>> Laurent Goubet
>> Obeo
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-8jPJ4+XcA8/rwM8OmdDA--
|
|
|
| Re: OCL type checking [message #70613 is a reply to message #70598] |
Thu, 07 May 2009 15:32 |
|
This is a multi-part message in MIME format.
--------------070506020506030503090400
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
I was investigating this in the scope of the Acceleo project and yes,
we've also tried pushing things in the MTL specification. That sometimes
seem like an hopeless task :p.
As a side note, is there a reason why none of the "default"
UMLReflection implementations (both for UML and ecore environments)
aren't open API? I understand that this makes even more API to maintain
but UMLReflection is the typical exemple of hard and tedious to
reimplement interface. Especially when we only need to override one of
its 54 methods :p.
Laurent Goubet
Obeo
Christian W. Damus a écrit :
> Hi, Laurent,
>
> On the flip side, sometimes deviation is good because it is practically
> useful. :-) Especially with in the case of some specs. :-D
>
> Goodness knows that the MDT OCL implementation already has more than its
> share of deviations, some intended and more not. The problem with
> deviation from spec is, of course, portability of models to other
> implementations. So, it would be more beneficial for everyone to
> improve the spec by the addition of capabilities like "typeSelect" but
> that is more difficult than just implementing them :-(
>
> cW
>
> On Thu, 2009-05-07 at 15:28 +0200, laurent Goubet wrote:
>> Hi Christian,
>>
>> Indeed, this can be seen as a deviation from the spec, didn't really
>> look at it that way :p.
>>
>> Thanks for the insight.
>>
>> Laurent Goubet
>> Obeo
>>
>> Christian W. Damus a écrit :
>> > Hi, Laurent,
>> >
>> > If I'm not mistaken, there was some discussion of this in the context of
>> > QVT's need to modify the semantics of the OCL library. But, I think
>> > those changes are incompatible from an API contract perspective, so they
>> > were taken back to OMG as spec issues.
>> >
>> > Unfortunately, changing the result type of a standard library operation
>> > would be quite a deviation from the spec. It would be much nicer to be
>> > able to define, in OCL or Java, a "typeSelect" operation for collections
>> > (a la Xtend/Xpand). That isn't possible currently, as the specification
>> > of type arguments in oclAsType (and consequently an hypothetical
>> > typeSelect) is flawed. The changes already adopted by OMG for the OCL
>> > 2.1 revision should address that problem (specifically, doing away with
>> > TypeType metaclass and OclType, using the Classifier metaclass instead).
>> >
>> > Cheers,
>> >
>> > Christian
>> >
>> > On Thu, 2009-05-07 at 14:50 +0200, laurent Goubet wrote:
>> >> Hi,
>> >>
>> >> I recently looked at the changes introduced in OCL with the inclusion of
>> >> the TypeChecker interface ( through bug
>> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=233673 ).
>> >>
>> >> This gives third-party plugins a great deal of capabilities in dynamic
>> >> typing of custom operations and the such, yet I think some of the
>> >> standard operations could also benefit from this. The most obvious
>> >> example I have in mind would be something like this :
>> >> "randomList->select(oclIsKindOf(Type))"
>> >>
>> >> At current, a user doing such a select operation will need to cast the
>> >> result in order to use its specific operations. Consider something like
>> >> this :
>> >> "randomList-> select(oclIsKindOf(ENamedElement)).oclAsType(ENamedElement). name "
>> >>
>> >>
>> >> I know there are way more complicated things than this that can happen
>> >> in an iterate; but at least those cases are obvious... and pretty
>> >> frequent. If I am not mistaken, the impossibility to type the result of
>> >> a select comes from line 3709 of AbstractOCLAnalyzer :
>> >> 3708 } else if (name.equals("select") || name.equals("reject"))
>> >> {//$NON-NLS-2$//$NON-NLS-1$
>> >> 3709 astNode.setType(source.getType());
>> >>
>> >> Would there be any way to leverage the new TypeChecker in such cases or
>> >> was that a deliberate overlook?
>> >>
>> >> Regards,
>> >>
>> >> Laurent Goubet
>> >> Obeo
>>
--------------070506020506030503090400
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
--------------070506020506030503090400--
|
|
|
| Re: OCL type checking [message #70646 is a reply to message #70613] |
Fri, 08 May 2009 12:26 |
|
--=-fuFDBUcT+o55AlfSi3ZK
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi, Laurent,
Much of the OCL code was published as API before it was truly ready.
The component went to release 1.0 in EMFT in the early days before the
Modeling Project came into being and before the now well-established
pattern of running up to 1.0 with 0.7, 0.8, and 0.9 releases. So, I
tried in recent years to be extra careful about adding new API, and
sitting down to figure out how much of a UMLReflection implementation
class should be public or protected API for clients/subclasses to use
just never fit into the plan.
Of course, that doesn't mean that you can't re-use the existing
implementation. Delegation may work well in this case.
Cheers,
Christian
On Thu, 2009-05-07 at 17:32 +0200, laurent Goubet wrote:
> I was investigating this in the scope of the Acceleo project and yes,=20
> we've also tried pushing things in the MTL specification. That sometimes=20
> seem like an hopeless task :p.
>=20
> As a side note, is there a reason why none of the "default"=20
> UMLReflection implementations (both for UML and ecore environments)=20
> aren't open API? I understand that this makes even more API to maintain=20
> but UMLReflection is the typical exemple of hard and tedious to=20
> reimplement interface. Especially when we only need to override one of=20
> its 54 methods :p.
>=20
> Laurent Goubet
> Obeo
>=20
> Christian W. Damus a =C3=A9crit :
> > Hi, Laurent,
> >=20
> > On the flip side, sometimes deviation is good because it is practically=
=20
> > useful. :-) Especially with in the case of some specs. :-D
> >=20
> > Goodness knows that the MDT OCL implementation already has more than it=
s=20
> > share of deviations, some intended and more not. The problem with=20
> > deviation from spec is, of course, portability of models to other=20
> > implementations. So, it would be more beneficial for everyone to=20
> > improve the spec by the addition of capabilities like "typeSelect" but=20
> > that is more difficult than just implementing them :-(
> >=20
> > cW
> >=20
> > On Thu, 2009-05-07 at 15:28 +0200, laurent Goubet wrote:
> >> Hi Christian,
> >>
> >> Indeed, this can be seen as a deviation from the spec, didn't really=20
> >> look at it that way :p.
> >>
> >> Thanks for the insight.
> >>
> >> Laurent Goubet
> >> Obeo
> >>
> >> Christian W. Damus a =C3=A9crit :
> >> > Hi, Laurent,
> >> >=20
> >> > If I'm not mistaken, there was some discussion of this in the contex=
t of=20
> >> > QVT's need to modify the semantics of the OCL library. But, I think=
=20
> >> > those changes are incompatible from an API contract perspective, so =
they=20
> >> > were taken back to OMG as spec issues.
> >> >=20
> >> > Unfortunately, changing the result type of a standard library operat=
ion=20
> >> > would be quite a deviation from the spec. It would be much nicer to=
be=20
> >> > able to define, in OCL or Java, a "typeSelect" operation for collect=
ions=20
> >> > (a la Xtend/Xpand). That isn't possible currently, as the specifica=
tion=20
> >> > of type arguments in oclAsType (and consequently an hypothetical=20
> >> > typeSelect) is flawed. The changes already adopted by OMG for the O=
CL=20
> >> > 2.1 revision should address that problem (specifically, doing away w=
ith=20
> >> > TypeType metaclass and OclType, using the Classifier metaclass inste=
ad).
> >> >=20
> >> > Cheers,
> >> >=20
> >> > Christian
> >> >=20
> >> > On Thu, 2009-05-07 at 14:50 +0200, laurent Goubet wrote:
> >> >> Hi,
> >> >>
> >> >> I recently looked at the changes introduced in OCL with the inclusi=
on of=20
> >> >> the TypeChecker interface ( through bug=20
> >> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D233673 ).
> >> >>
> >> >> This gives third-party plugins a great deal of capabilities in dyna=
mic=20
> >> >> typing of custom operations and the such, yet I think some of the=20
> >> >> standard operations could also benefit from this. The most obvious=20
> >> >> example I have in mind would be something like this :
> >> >> "randomList->select(oclIsKindOf(Type))"
> >> >>
> >> >> At current, a user doing such a select operation will need to cast =
the=20
> >> >> result in order to use its specific operations. Consider something =
like=20
> >> >> this :
> >> >> "randomList->select(oclIsKindOf(ENamedElement)).oclAsType(ENamedEle=
ment).name"=20
> >> >>
> >> >>
> >> >> I know there are way more complicated things than this that can hap=
pen=20
> >> >> in an iterate; but at least those cases are obvious... and pretty=20
> >> >> frequent. If I am not mistaken, the impossibility to type the resul=
t of=20
> >> >> a select comes from line 3709 of AbstractOCLAnalyzer :
> >> >> 3708 } else if (name.equals("select") || name.equals("reject"))=20
> >> >> {//$NON-NLS-2$//$NON-NLS-1$
> >> >> 3709 astNode.setType(source.getType());
> >> >>
> >> >> Would there be any way to leverage the new TypeChecker in such case=
s or=20
> >> >> was that a deliberate overlook?
> >> >>
> >> >> Regards,
> >> >>
> >> >> Laurent Goubet
> >> >> Obeo
> >>
>=20
--=-fuFDBUcT+o55AlfSi3ZK
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.24.1.1">
</HEAD>
<BODY>
Hi, Laurent,<BR>
<BR>
Much of the OCL code was published as API before it was truly ready. The component went to release 1.0 in EMFT in the early days before the Modeling Project came into being and before the now well-established pattern of running up to 1.0 with 0.7, 0.8, and 0.9 releases. So, I tried in recent years to be extra careful about adding new API, and sitting down to figure out how much of a UMLReflection implementation class should be public or protected API for clients/subclasses to use just never fit into the plan.<BR>
<BR>
Of course, that doesn't mean that you can't re-use the existing implementation. Delegation may work well in this case.<BR>
<BR>
Cheers,<BR>
<BR>
Christian<BR>
<BR>
On Thu, 2009-05-07 at 17:32 +0200, laurent Goubet wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
I was investigating this in the scope of the Acceleo project and yes,
we've also tried pushing things in the MTL specification. That sometimes
seem like an hopeless task :p.
As a side note, is there a reason why none of the "default"
UMLReflection implementations (both for UML and ecore environments)
aren't open API? I understand that this makes even more API to maintain
but UMLReflection is the typical exemple of hard and tedious to
reimplement interface. Especially when we only need to override one of
its 54 methods :p.
Laurent Goubet
Obeo
Christian W. Damus a écrit :
> Hi, Laurent,
>
> On the flip side, sometimes deviation is good because it is practically
> useful. :-) Especially with in the case of some specs. :-D
>
> Goodness knows that the MDT OCL implementation already has more than its
> share of deviations, some intended and more not. The problem with
> deviation from spec is, of course, portability of models to other
> implementations. So, it would be more beneficial for everyone to
> improve the spec by the addition of capabilities like "typeSelect" but
> that is more difficult than just implementing them :-(
>
> cW
>
> On Thu, 2009-05-07 at 15:28 +0200, laurent Goubet wrote:
>> Hi Christian,
>>
>> Indeed, this can be seen as a deviation from the spec, didn't really
>> look at it that way :p.
>>
>> Thanks for the insight.
>>
>> Laurent Goubet
>> Obeo
>>
>> Christian W. Damus a écrit :
>> > Hi, Laurent,
>> >
>> > If I'm not mistaken, there was some discussion of this in the context of
>> > QVT's need to modify the semantics of the OCL library. But, I think
>> > those changes are incompatible from an API contract perspective, so they
>> > were taken back to OMG as spec issues.
>> >
>> > Unfortunately, changing the result type of a standard library operation
>> > would be quite a deviation from the spec. It would be much nicer to be
>> > able to define, in OCL or Java, a "typeSelect" operation for collections
>> > (a la Xtend/Xpand). That isn't possible currently, as the specification
>> > of type arguments in oclAsType (and consequently an hypothetical
>> > typeSelect) is flawed. The changes already adopted by OMG for the OCL
>> > 2.1 revision should address that problem (specifically, doing away with
>> > TypeType metaclass and OclType, using the Classifier metaclass instead).
>> >
>> > Cheers,
>> >
>> > Christian
>> >
>> > On Thu, 2009-05-07 at 14:50 +0200, laurent Goubet wrote:
>> >> Hi,
>> >>
>> >> I recently looked at the changes introduced in OCL with the inclusion of
>> >> the TypeChecker interface ( through bug
>> >> <A HREF="https://bugs.eclipse.org/bugs/show_bug.cgi?id=233673">https://bugs.eclipse.org/bugs/show_bug.cgi?id=233673</A> ).
>> >>
>> >> This gives third-party plugins a great deal of capabilities in dynamic
>> >> typing of custom operations and the such, yet I think some of the
>> >> standard operations could also benefit from this. The most obvious
>> >> example I have in mind would be something like this :
>> >> "randomList->select(oclIsKindOf(Type))&q uot;
>> >>
>> >> At current, a user doing such a select operation will need to cast the
>> >> result in order to use its specific operations. Consider something like
>> >> this :
>> >> "randomList->select(oclIsKindOf(ENamedElemen t)).oclAsType(ENamedElement).name"
>> >>
>> >>
>> >> I know there are way more complicated things than this that can happen
>> >> in an iterate; but at least those cases are obvious... and pretty
>> >> frequent. If I am not mistaken, the impossibility to type the result of
>> >> a select comes from line 3709 of AbstractOCLAnalyzer :
>> >> 3708 } else if (name.equals("select") || name.equals("reject"))
>> >> {//$NON-NLS-2$//$NON-NLS-1$
>> >> 3709 astNode.setType(source.getType());
>> >>
>> >> Would there be any way to leverage the new TypeChecker in such cases or
>> >> was that a deliberate overlook?
>> >>
>> >> Regards,
>> >>
>> >> Laurent Goubet
>> >> Obeo
>>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-fuFDBUcT+o55AlfSi3ZK--
|
|
|
| Re: OCL type checking [message #70722 is a reply to message #70646] |
Wed, 13 May 2009 09:19 |
|
This is a multi-part message in MIME format.
--------------030205020201030106030306
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Hi Christian,
Yup, delegation is the choice I ended up making (UMLReflection is just
too tedious to reimplement, and I am a lazy bum :p). I understand the
problem you faced with this "API or not API" question ... and I won't
try to push into making it API as I know how much work it can be to
maintain. Especially so since it can be worked around through delegation.
Laurent Goubet
Obeo
Christian W. Damus a écrit :
> Hi, Laurent,
>
> Much of the OCL code was published as API before it was truly ready.
> The component went to release 1.0 in EMFT in the early days before the
> Modeling Project came into being and before the now well-established
> pattern of running up to 1.0 with 0.7, 0.8, and 0.9 releases. So, I
> tried in recent years to be extra careful about adding new API, and
> sitting down to figure out how much of a UMLReflection implementation
> class should be public or protected API for clients/subclasses to use
> just never fit into the plan.
>
> Of course, that doesn't mean that you can't re-use the existing
> implementation. Delegation may work well in this case.
>
> Cheers,
>
> Christian
>
> On Thu, 2009-05-07 at 17:32 +0200, laurent Goubet wrote:
>> I was investigating this in the scope of the Acceleo project and yes,
>> we've also tried pushing things in the MTL specification. That sometimes
>> seem like an hopeless task :p.
>>
>> As a side note, is there a reason why none of the "default"
>> UMLReflection implementations (both for UML and ecore environments)
>> aren't open API? I understand that this makes even more API to maintain
>> but UMLReflection is the typical exemple of hard and tedious to
>> reimplement interface. Especially when we only need to override one of
>> its 54 methods :p.
>>
>> Laurent Goubet
>> Obeo
>>
>> Christian W. Damus a écrit :
>> > Hi, Laurent,
>> >
>> > On the flip side, sometimes deviation is good because it is practically
>> > useful. :-) Especially with in the case of some specs. :-D
>> >
>> > Goodness knows that the MDT OCL implementation already has more than its
>> > share of deviations, some intended and more not. The problem with
>> > deviation from spec is, of course, portability of models to other
>> > implementations. So, it would be more beneficial for everyone to
>> > improve the spec by the addition of capabilities like "typeSelect" but
>> > that is more difficult than just implementing them :-(
>> >
>> > cW
>> >
>> > On Thu, 2009-05-07 at 15:28 +0200, laurent Goubet wrote:
>> >> Hi Christian,
>> >>
>> >> Indeed, this can be seen as a deviation from the spec, didn't really
>> >> look at it that way :p.
>> >>
>> >> Thanks for the insight.
>> >>
>> >> Laurent Goubet
>> >> Obeo
>> >>
>> >> Christian W. Damus a écrit :
>> >> > Hi, Laurent,
>> >> >
>> >> > If I'm not mistaken, there was some discussion of this in the context of
>> >> > QVT's need to modify the semantics of the OCL library. But, I think
>> >> > those changes are incompatible from an API contract perspective, so they
>> >> > were taken back to OMG as spec issues.
>> >> >
>> >> > Unfortunately, changing the result type of a standard library operation
>> >> > would be quite a deviation from the spec. It would be much nicer to be
>> >> > able to define, in OCL or Java, a "typeSelect" operation for collections
>> >> > (a la Xtend/Xpand). That isn't possible currently, as the specification
>> >> > of type arguments in oclAsType (and consequently an hypothetical
>> >> > typeSelect) is flawed. The changes already adopted by OMG for the OCL
>> >> > 2.1 revision should address that problem (specifically, doing away with
>> >> > TypeType metaclass and OclType, using the Classifier metaclass instead).
>> >> >
>> >> > Cheers,
>> >> >
>> >> > Christian
>> >> >
>> >> > On Thu, 2009-05-07 at 14:50 +0200, laurent Goubet wrote:
>> >> >> Hi,
>> >> >>
>> >> >> I recently looked at the changes introduced in OCL with the inclusion of
>> >> >> the TypeChecker interface ( through bug
>> >> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=233673 ).
>> >> >>
>> >> >> This gives third-party plugins a great deal of capabilities in dynamic
>> >> >> typing of custom operations and the such, yet I think some of the
>> >> >> standard operations could also benefit from this. The most obvious
>> >> >> example I have in mind would be something like this :
>> >> >> "randomList->select(oclIsKindOf(Type))"
>> >> >>
>> >> >> At current, a user doing such a select operation will need to cast the
>> >> >> result in order to use its specific operations. Consider something like
>> >> >> this :
>> >> >> "randomList-> select(oclIsKindOf(ENamedElement)).oclAsType(ENamedElement). name "
>> >> >>
>> >> >>
>> >> >> I know there are way more complicated things than this that can happen
>> >> >> in an iterate; but at least those cases are obvious... and pretty
>> >> >> frequent. If I am not mistaken, the impossibility to type the result of
>> >> >> a select comes from line 3709 of AbstractOCLAnalyzer :
>> >> >> 3708 } else if (name.equals("select") || name.equals("reject"))
>> >> >> {//$NON-NLS-2$//$NON-NLS-1$
>> >> >> 3709 astNode.setType(source.getType());
>> >> >>
>> >> >> Would there be any way to leverage the new TypeChecker in such cases or
>> >> >> was that a deliberate overlook?
>> >> >>
>> >> >> Regards,
>> >> >>
>> >> >> Laurent Goubet
>> >> >> Obeo
>> >>
>>
--------------030205020201030106030306
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
--------------030205020201030106030306--
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 19:31:34 GMT 2024
Powered by FUDForum. Page generated in 0.03666 seconds |
] 
Search
Help
Register
Login
Home
