Hi Laurent, Axel
I certainly agree that '*' is not a priority.
It is an example of where the corrolary of total UML alignment has
gone.
Multiplicity can be unlimited.
Integer cannot, so need a new type UnlimitedNatural.
- but don't bother to specify it.
This is where I joined in and wrote the missing specification.
Oops UnlimitedNatural conforms to Integer, but '*' is
UnlimitedNatural and does not conform to Integer.
- specification therefore says it must conform via invalid.
New suggestion; rename as +infinity and support for Integer and
Real.
Further corrolary; then what use is UnlimitedNatural at all? (Only
just realised this)
Why not just introduce +infinity to Intreger and Real and have done
with it.
Regards
Ed
On 19/04/2011 10:06, Laurent Goubet wrote:
Axel,
"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 :).
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.
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
No virus found in
this message.
Checked by AVG - www.avg.com
Version: 10.0.1209 / Virus Database: 1500/3582 - Release Date:
04/18/11
|
