Hi Alex
On 21/01/2010 08:18, Alexander Igdalov wrote:
Hi Ed,
It seems to be a weird
example. Why should someone use implicit convertion to a collection and
use a collection operation when there is a simpler way to express it:
self.wife.oclIsUndefined() implies
self.wife.gender = Gender::female
?
True. It's a stupid example and apart from the oclCamelCase is easier
to read.
A more realistic example comes from thinking about null.
null is an undefined instance of any type.
Set{null} is defined collection containing one undefined instance.
Set{} is a defined collection containing no instance.
I think that it would be very wrong for null->size() = 1 to be true
and null->isEmpty() to be false.
I would rather ban null conversion to not-null altogether than convert
null to Set{null}.
Thinking more about the implicit conversion to
collections using an arrow, I cannot invent any good use case where it
could be helpful... It seems that it could be equally well expressed
using other language constructions. Do you agree?
As regards the collection type (Bag, Set or
other), I think it doesn't matter much. Set is more backwards
compatible but Bag fits too.
I have a weak preference for Collection.
Set is more MDT/OCL compatible since the Bag{} conversion is not
implemented.
Bag is less useful and so forces an explicit asSet() if anything clever
is to be performed.
Collection is even less useful and so forces an explicit asXxx() if
anything clever is to be performed
Ed
Hi Alex
The purpose of the conversion is to make 0..1 properties easy to use.
Thus in 7.5.3 "Navigation over Associations with Multiplicity Zero or
One" we get
self.wife->notEmpty() implies self.wife.gender = Gender::female
so creation of Set{null} would completely invalidate the usage.
My raised issue has now been allocated Issue 14981.
Bag{} and Set{x} are not quite contradictory, just a little
inconsistent. The issue suggests
changing to Bag{} and Bag{x}, so that the compile-time type is
predictable. I changed
the MDT-OCL 1.3.0 synthesis of Set{x}-> to x.oclAsCollection()->
so that the null-ness
of x determines the collection content. Unfortunatel;y
Collection<T> is insufficient to allow
some exiusting unit tests to work that expect Set.
Ed
On 20/01/2010 18:35, Alexander Igdalov wrote:
Hi
all,
The
resolution of issue 10438 made `null->foo()` a synonym of
`Bag{}->foo()`. As Ed has mentioned earlier this contradicts 7.5.3
which suggests wrapping the _expression_ source to a Set, i.e.
`x->foo()` becomes `Set{x}->foo()` if `x` is not a collection.
Does
anyone see why there is that exception from the general rule for null?
If not I will raise an OMG issue for that.
Since
`null->foo()` is allowed, what should it be converted to? Should it
be `Set{}->foo()` or `Set{null}->foo()`? I would prefer the
latter because only in this case we could construct a complete AST at
compile time (see guideline at 9.6).
Regards,
-
Alex.
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.730 / Virus Database: 271.1.1/2634 - Release Date: 01/20/10 09:12:00
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.730 / Virus Database: 271.1.1/2634 - Release Date: 01/20/10 09:12:00
|