[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] Question regarding operations on UnlimitedNatur al taking UnlimitedNatural argument
|
Hi Laurent,
"I think I got the invalid/null stuff under control using Laurent's tests."
To tell you the truth, I initially wrote these tests with the hope to
refactor the EvaluationVisitorImpl ... and gave up when I saw the sheer
number of failures my tests highlighted. Kudos for fixing these, I
didn't expect anyone to have the courage :).
well, there were a few categories of problems that I didn't have the
courage (aka: time) to fix either. In particular, there are still issues
with the lookup of operations on collections where collection type
conformance is not considered correctly; also, the dreaded
representation of UnlimitedNatural.UNLIMITED as -1 still causes trouble
when explicitly comparing. I haven't come around to properly convert
UNLIMITED to invalid in case a conversion to Integer is required to
perform the operation. This also has to do with non-negative number
literals currently being parsed as Integer literals instead of
UnlimitedNatural literals. Last but not least, the numeric equality
discrepancies between the Java and the OCL type system remain unresolved
(see separate discussion thread). In particular, when 3 and 3.0 are
inserted into a java.util.Set which is then submitted into the OCL
evaluator, problems may result because the Java collections use Java
.equals whereas individual objects in OCL are compared using
ObjectUtil.equal which considers 3.0 and 3 equal. The tests from those
three areas that still failed are commented out on my local branch.
I'm just trying to fix the major conformance obstacles, particularly in
the areas of null/invalid, where it strikes users and where the issues
are hard if not impossible to work around.
I see a way forward where we try to get Ed's cleaned-up evaluator fitted
onto the Ecore-specific architecture. This would get conformance as well
as maintainability to a new, much improved level but obviously would
have to happen after Indigo.
As for the "unlimited natural" part of my unit tests ... I truly doubt
that there is any benefit from fixing them : few people will even
realize that "*" parses as a special value; and even for those that do,
who in the world (except the nasty jerk that wrote these unit tests :p)
would write anything that uses this value? I don't even really
understand why it is mentionned in the OCL specification, but I don't
think it has any other use than the " = " and " <>" operations to check
the upper bound of a reference. Really, why would we want to write
something like :
"*.abs()"
"* * *"
"* / 1"
...
I think these parts of my unit tests should be commented out/deleted.
Fixing the unlimited issue is too much trouble for the "mature" OCL : it
might be fixed in the future pivot-based implementation ... but even
there I don't think it should be a priority.
Just my 2 cents.
Thanks a bunch! Truly helpful.
Best regards,
-- Axel
Laurent Goubet
Obeo
On 19/04/2011 09:25, Axel Uhl wrote:
Aside from the 3.0 vs. 3 issue particularly in collections and the
polymorphic collection operation lookup that doesn't work as expected,
I think I got the invalid/null stuff under control using Laurent's
tests. After commenting the collections tests with a FIXME where
inherited operation specs are not found, and after commenting the 3.0
vs. 3 issues, also with a FIXME, I have only 9 failures left which all
have to do with UnlimitedNatural. Those, however, are nasty
particularly because the Integer-defined operations are not resolved
for an UnlimitedInteger. So if we parsed non-negative integer literals
as UnlimitedNaturalLiteral we'd currently mess things up as 1.+(-1)
wouldn't be resolved because -1 is not an UnlimitedNatural, 1 is, and
we have UnlimitedNatural::+(UnlimitedNatural), and Integer::+(Integer)
is not found.
I'm inclined to at least for the special case of UnlimitedNatural
introduce the superclass lookup in
AbstractTypeChecker.findOperationMatching. This would solve the nasty
UnlimitedNatural issue reliably, I think. I'll give it a try.
Best,
-- Axel
On 4/18/2011 4:30 PM, Willink, Ed wrote:
HI Axel
It's not easy. - I gave up.
The mature parser was written before UnlimitedNatural was properly
identified. I think only '*' is parsed as unlimited natural, although
all
non-negative integers should be.
1.oclIsTypeOf(UnlimitedNatural) = true.
'*' really is a mess, requiring conversion to invalid when assigned to
Integer variable.
I have raised an OMG issue suggesting that +infinity, at least, exist
for
all numerics.
------------------------------
I suggest that you try to bound your ambition to correct the mature
code.
My intention was to do just 1% of the fixes and move on to the pivot
for the
100%.
You may well be able to do 50%, perhaps even 75%, but is that really
worth
it?
Regards
Ed
-----Original Message-----
From: mdt-ocl.dev-bounces@xxxxxxxxxxx
[mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx] On Behalf Of Axel Uhl
Sent: 18 April 2011 15:22
To: MDT OCL mailing list
Subject: [mdt-ocl.dev] Question regarding operations on
UnlimitedNatural taking UnlimitedNatural argument
Hi,
there are operations defined on UnlimitedNatural in the 2.3
spec which
as argument take an UnlimitedNatural (e.g., div, mod, max,
min and the
comparison operations). The current parser creates IntegerLiteralExp
expressions for non-negative integer literals such as 0, 1, ...
This leads to a glitch for expressions such as
*.div(1)
because * parses to an UnlimitedNaturalLiteralExp, 1 parses to an
IntegerLiteralExp, Integer does not conform to UnlimitedNatural and
hence the operation UnlimitedNatural::div(UnlimitedNatural) is not
applicable.
Now, Integer::div(Integer) would be applicable, but it's not
clear to me
whether these operations should be visible for the specialization
UnlimitedNatural. What's your take on this?
Currently, the "mature" implementation for Ecore gives up on any
expression of this sort, and I wonder whether and how to fix it.
Best,
-- Axel
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
Please consider the environment before printing a hard copy of this
e-mail.
The information contained in this e-mail is confidential. It is intended
only for the stated addressee(s) and access to it by any other person is
unauthorised. If you are not an addressee, you must not disclose, copy,
circulate or in any other way use or rely on the information
contained in
this e-mail. Such unauthorised use may be unlawful. If you have received
this e-mail in error, please inform us immediately on +44 (0)118 986
8601
and delete it and all copies from your system.
Thales Research and Technology (UK) Limited. A company registered in
England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne
Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered
Number:
774298
Thales UK Limited. A company registered in England and Wales. Registered
Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone,
Weybridge, Surrey KT15 2NX. Registered Number: 868273
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
