Hi Ed,
I think that
it would be very wrong for null->size() = 1 to be true and null->isEmpty()
to be false.
I think of it just as of notation equal to wrapping null into
a collection containing one undefined instance. Therefore, I don't find it
incorrect that null->size()=1 is true and
null->isEmpty() is false. IMO you just don't like the way
it looks because it provokes to think of
null->size() as of "size of
undefined value" and
null->isEmpty() as of
"validation of emptiness of undefined value".
I would rather ban null
conversion to not-null altogether than convert null to
Set{null}.
I would rather ban the whole conversion to single-value
collection itself since I cannot invent use cases which would make this language
construction sensible. But I think it is impossible due to compatibility
considerations.
Cheers,
-
Alex.
P.S.
BTW, I
thought you would say that the exceptional conversion of null into an
empty collection would be a breakage of the Liskov Substitution
Principle...
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
