Home » Modeling » OCL » Type conformance issues
| |
| Re: Type conformance issues [message #61675 is a reply to message #61617] |
Thu, 28 August 2008 12:44   |
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 #61722 is a reply to message #61675] |
Fri, 29 August 2008 01:07 |
 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] |
Fri, 29 August 2008 01:22 |
| 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 #61793 is a reply to message #61769] |
Fri, 29 August 2008 11:35 |
| 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
>
>
|
|
|
Goto Forum:
Current Time: Sat Apr 20 02:56:35 GMT 2024
Powered by FUDForum. Page generated in 0.02826 seconds |
] 
Search
Help
Register
Login
Home
