Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Type conformance issues
Type conformance issues [message #61617] Tue, 26 August 2008 19:21 Go to next message
Stefan Schulze is currently offline Stefan Schulze
Messages: 70
Registered: July 2009
Member
Hi...

I think there are different kinds of typeconformance-checks in the
implementation. These differences are striking, if you use an EDatatype with
name "OwnInteger" and instanceClass java.lang.Integer in the usermodel:

- In the variable-section of let-expressions and the accumulator-definition
of iterate-expressions, TypeUtil#typeCompare(..) is used while validation.
This causes "let i:OwnInteger=5 in i" fail because IntegerLiteral is no
valid OwnInteger.

- For looking up an operation which matches the given arguments,
UMLReflectionImpl#getOCLTypeFor(...) is used. This causes, that an operation
defined as foo(OwnInteger) matches the operation foo(Integer). The call
foo(5) matches, too.

- If an operation is called on an user type, it is converted to an OCL
standard type before retrieving the available operations
(UMLReflectionImpl#getOCLTypeFor(...)


I would prefer the version with converting the user type.
Is it possible to get the conversion for the first case? I thought about
building the AST, traversing it to search for VariableExps and modifing them
manually before the validation is performed. Unfortunately I can't get
between parseInvOrDefCS() and validate(...) in HelperUtil#parseQuery(...)
and I can neither call HelperUtil#validate(...) manually nor accessing the
ValidationVisitor due to "discouraged access".
Is there any alternative to modify the AST before validation? If not, is the
validation important or are the most problems found during building the
tree?

Stefan
Re: Type conformance issues [message #61651 is a reply to message #61617] Tue, 26 August 2008 19:46 Go to previous messageGo to next message
Stefan Schulze is currently offline Stefan Schulze
Messages: 70
Registered: July 2009
Member
"Stefan Schulze" <algroth@gmx.de> schrieb im Newsbeitrag
news:g9235s$v81$1@build.eclipse.org...
> - For looking up an operation which matches the given arguments,
> UMLReflectionImpl#getOCLTypeFor(...) is used. This causes, that an
> operation defined as foo(OwnInteger) matches the operation foo(Integer).
> The call foo(5) matches, too.

Only the specified parameter is converted. So the call foo(Integer) matches
the specified Operation foo(OwnInteger), but the call foo(OwnInteger) does
not match the specified foo(Integer).
The conversion of the user type is only applied to the parameter type but
not the argument type.

Stefan
Re: Type conformance issues [message #61675 is a reply to message #61617] Thu, 28 August 2008 08:44 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Hi, Stefan,

Heh heh ... You're good at unearthing the deepest, darkest corners of
this OCL implementation, aren't you? ;-)

Seriously, though, I expect that you realize that all of this coercion
of data-types to the OCL standard types is unabashedly non-conformant.
I could suggest that much of what getOCLTypeFor() does should simply be
struck out, and that may be a good idea for the 2.0 release, possibly
with an Option to do these non-conformant conversions where a model
needs them for practical reasons (such as being tied to model libraries
of Java or C++ types).

In the mean-time, you certainly have identified an inconsistency that is
worth fixing. You could raise a bugzilla. Perhaps you'd like to take
the opportunity to contribute a patch along with it? It sounds like a
nice entry-level fix ... :-)

cW

Stefan Schulze wrote:
> Hi...
>
> I think there are different kinds of typeconformance-checks in the
> implementation. These differences are striking, if you use an EDatatype with
> name "OwnInteger" and instanceClass java.lang.Integer in the usermodel:
>
> - In the variable-section of let-expressions and the accumulator-definition
> of iterate-expressions, TypeUtil#typeCompare(..) is used while validation.
> This causes "let i:OwnInteger=5 in i" fail because IntegerLiteral is no
> valid OwnInteger.
>
> - For looking up an operation which matches the given arguments,
> UMLReflectionImpl#getOCLTypeFor(...) is used. This causes, that an operation
> defined as foo(OwnInteger) matches the operation foo(Integer). The call
> foo(5) matches, too.
>
> - If an operation is called on an user type, it is converted to an OCL
> standard type before retrieving the available operations
> (UMLReflectionImpl#getOCLTypeFor(...)
>
>
> I would prefer the version with converting the user type.
> Is it possible to get the conversion for the first case? I thought about
> building the AST, traversing it to search for VariableExps and modifing them
> manually before the validation is performed. Unfortunately I can't get
> between parseInvOrDefCS() and validate(...) in HelperUtil#parseQuery(...)
> and I can neither call HelperUtil#validate(...) manually nor accessing the
> ValidationVisitor due to "discouraged access".
> Is there any alternative to modify the AST before validation? If not, is the
> validation important or are the most problems found during building the
> tree?
>
> Stefan
>
>
Re: Type conformance issues [message #61700 is a reply to message #61675] Thu, 28 August 2008 19:35 Go to previous messageGo to next message
Stefan Schulze is currently offline Stefan Schulze
Messages: 70
Registered: July 2009
Member
"Christian W. Damus" <cdamus@zeligsoft.com> schrieb im Newsbeitrag
news:g966j9$oe8$1@build.eclipse.org...
> In the mean-time, you certainly have identified an inconsistency that is
> worth fixing. You could raise a bugzilla. Perhaps you'd like to take the
> opportunity to contribute a patch along with it? It sounds like a nice
> entry-level fix ... :-)

I would really be happy if I could contribute...
I'm currently working on this patch and I have another question:
As I said, the owner of an operation is tried to convert to the appropriate
PredefinedType. If this is possible, this type is used.
So if I define an OwnInteger with the additional operation
OwnInteger::getSqrt():Real, this method will never been called.
I'm not sure whether this is a theoretical problem or not because I think
you can't define an EOperation on an EDataType.

Does it makes sense to implement something like an override-mechanism (of
course not part of the future strict conformance)?
Defined methods:
OwnInteger::+(Integer):Integer
OwnInteger::getSqrt():Real
Integer::+(Integer):Integer
Integer::-(Integer):Integer

Callable methods:
OwnInteger::+(Integer):Integer
OwnInteger::getSqrt():Real
Integer::-(Integer):Integer
The method Integer::+(Integer):Integer is "overridden" by
OwnInteger::+(Integer):Integer.

Stefan
Re: Type conformance issues [message #61722 is a reply to message #61675] Thu, 28 August 2008 21:07 Go to previous messageGo to next message
Stefan Schulze is currently offline Stefan Schulze
Messages: 70
Registered: July 2009
Member
Hi Christian,

I created a patch for TypeUtil @1.11 by simply adding
+ type1=env.getUMLReflection().getOCLType(type1);
+ type2=env.getUMLReflection().getOCLType(type2);
to the beginning of commonSuperType(...) and getRelationship(Environment,
....).

This fixes the inconsistent behavior I mentioned before (without the
overriding of methods), but I could not run the "official" testsuites
against the patched file, because I didn't found the matching tags that fits
an release of EMF.

Could you please tell me the tags for a valid configuration using an
release-version of EMF?

Stefan


"Christian W. Damus" <cdamus@zeligsoft.com> schrieb im Newsbeitrag
news:g966j9$oe8$1@build.eclipse.org...
> Hi, Stefan,
>
> Heh heh ... You're good at unearthing the deepest, darkest corners of
> this OCL implementation, aren't you? ;-)
>
> Seriously, though, I expect that you realize that all of this coercion of
> data-types to the OCL standard types is unabashedly non-conformant. I
> could suggest that much of what getOCLTypeFor() does should simply be
> struck out, and that may be a good idea for the 2.0 release, possibly with
> an Option to do these non-conformant conversions where a model needs them
> for practical reasons (such as being tied to model libraries of Java or
> C++ types).
>
> In the mean-time, you certainly have identified an inconsistency that is
> worth fixing. You could raise a bugzilla. Perhaps you'd like to take the
> opportunity to contribute a patch along with it? It sounds like a nice
> entry-level fix ... :-)
>
> cW
>
> Stefan Schulze wrote:
>> Hi...
>>
>> I think there are different kinds of typeconformance-checks in the
>> implementation. These differences are striking, if you use an EDatatype
>> with name "OwnInteger" and instanceClass java.lang.Integer in the
>> usermodel:
>>
>> - In the variable-section of let-expressions and the
>> accumulator-definition of iterate-expressions, TypeUtil#typeCompare(..)
>> is used while validation. This causes "let i:OwnInteger=5 in i" fail
>> because IntegerLiteral is no valid OwnInteger.
>>
>> - For looking up an operation which matches the given arguments,
>> UMLReflectionImpl#getOCLTypeFor(...) is used. This causes, that an
>> operation defined as foo(OwnInteger) matches the operation foo(Integer).
>> The call foo(5) matches, too.
>>
>> - If an operation is called on an user type, it is converted to an OCL
>> standard type before retrieving the available operations
>> (UMLReflectionImpl#getOCLTypeFor(...)
>>
>>
>> I would prefer the version with converting the user type.
>> Is it possible to get the conversion for the first case? I thought about
>> building the AST, traversing it to search for VariableExps and modifing
>> them manually before the validation is performed. Unfortunately I can't
>> get between parseInvOrDefCS() and validate(...) in
>> HelperUtil#parseQuery(...) and I can neither call
>> HelperUtil#validate(...) manually nor accessing the ValidationVisitor due
>> to "discouraged access".
>> Is there any alternative to modify the AST before validation? If not, is
>> the validation important or are the most problems found during building
>> the tree?
>>
>> Stefan
Re: Type conformance issues [message #61745 is a reply to message #61722] Thu, 28 August 2008 21:22 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Hi, Stefan,

Thanks for making the effort to create a patch!

In the source code, the R1_2_1 tag is the latest release tag for the OCL
plug-ins. The corresponding EMF tag should be R2_4_0 or some such (it's
the 2.4 release). It's easier, though, if you install EMF in your PDE
target.

If you're still having trouble, then don't worry about the tests for
this little fix. I'll be running them anyway.

In order to contribute, I will need you to attach a patch to an actual
bugzilla, to help the EMO to keep track of the Intellectual Property
that you are giving up to Eclipse.

Thanks again!

cW


Stefan Schulze wrote:
> Hi Christian,
>
> I created a patch for TypeUtil @1.11 by simply adding
> + type1=env.getUMLReflection().getOCLType(type1);
> + type2=env.getUMLReflection().getOCLType(type2);
> to the beginning of commonSuperType(...) and getRelationship(Environment,
> ...).
>
> This fixes the inconsistent behavior I mentioned before (without the
> overriding of methods), but I could not run the "official" testsuites
> against the patched file, because I didn't found the matching tags that fits
> an release of EMF.
>
> Could you please tell me the tags for a valid configuration using an
> release-version of EMF?
>
> Stefan

-----8<-----
Re: Type conformance issues [message #61769 is a reply to message #61745] Thu, 28 August 2008 23:01 Go to previous messageGo to next message
Stefan Schulze is currently offline Stefan Schulze
Messages: 70
Registered: July 2009
Member
"Christian W. Damus" <cdamus@zeligsoft.com> schrieb im Newsbeitrag
news:g97j04$k0c$1@build.eclipse.org...
> In order to contribute, I will need you to attach a patch to an actual
> bugzilla, to help the EMO to keep track of the Intellectual Property that
> you are giving up to Eclipse.

Issue is filed at https://bugs.eclipse.org/bugs/show_bug.cgi?id=245619.

Ten tests fails with error and ten with failure. But these failures remains
if I undo my patch.
The failures are in the Serialization_Tests about "Unresolved reference
<null>" and the errors are in the "OCL Document Parsing Tests" and "Types
Validator Tests" because of "MalformedURLException: unknown protocol:
platform".

btw: "Intellectual Property" is a really impressive term for two lines of
code. ;)

Stefan
Re: Type conformance issues [message #61793 is a reply to message #61769] Fri, 29 August 2008 07:35 Go to previous message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Great! Thanks very much, Stefan.

BTW, those tests require the Eclipse run-time, so you need to run them
as "JUnit plug-in test." Alternatively, the
org.eclipse.ocl.standalone.tests project defines a test suite that
combines all three OCL test suites and sets up the EMF registries for
stand-alone execution (as a regular JUnit test).

Anyways, I expect I'll not find any problems.

Cheers,

Christian

Stefan Schulze wrote:
> "Christian W. Damus" <cdamus@zeligsoft.com> schrieb im Newsbeitrag
> news:g97j04$k0c$1@build.eclipse.org...
>> In order to contribute, I will need you to attach a patch to an actual
>> bugzilla, to help the EMO to keep track of the Intellectual Property that
>> you are giving up to Eclipse.
>
> Issue is filed at https://bugs.eclipse.org/bugs/show_bug.cgi?id=245619.
>
> Ten tests fails with error and ten with failure. But these failures remains
> if I undo my patch.
> The failures are in the Serialization_Tests about "Unresolved reference
> <null>" and the errors are in the "OCL Document Parsing Tests" and "Types
> Validator Tests" because of "MalformedURLException: unknown protocol:
> platform".
>
> btw: "Intellectual Property" is a really impressive term for two lines of
> code. ;)
>
> Stefan
>
>
Previous Topic:Invalid and OclInvalid
Next Topic:[Announce] MDT OCL 1.2.2 M200808290729 is available
Goto Forum:
  


Current Time: Mon Jul 28 00:30:41 EDT 2014

Powered by FUDForum. Page generated in 0.02291 seconds