Re: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2 : Issue 19146: Specify Lis

[Sergey Boyko <serg.boyko2011@xxxxxxxxx>]

Hi,

On Fri, Feb 7, 2014 at 12:10 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:

Hi Sergey

A List is not a Collection, and List has such bad characteristics that perhaps List should be made as hard as possible to use, certainly sufficiently so that Sequence is always used in preference.

(If you use List or Dict as a mapping argument, the List or Dict has to be deep-cloned before it contributes to the trace record! Oops QVTo bug.

Of course it does. QVTo recursively clones collections whenever they fall into trace record (not a deep-clone you mentioned). Since List and Dict are treated as collections they are certainly recursively cloned into trace storage.

 

If you pass a List to a mapping taking a Collection argument and List was a Collection, it would not be cloned and the trace record might then get corrupted when the List changes!).)

You can raise an issue for more more List operations.

Proposed design provokes rapid growth of quantity of collection's operations.

 

I don't see the implication that Collection::asList implies that List is a Collection. We have Sequence::asSequence().

    Regards

        Ed

   

On 07/02/2014 07:33, Sergey Boyko wrote:

Hi,

I have overlooked that "Issue 19146: Specify List::reject and other iterations." introduces two specializations for List operations:

excludesAll

    List(T)::excludesAll(c2 : Collection(T)) : Boolean

    List(T)::excludesAll(c2 : List(T)) : Boolean

includesAll

    List(T)::includesAll(c2 : Collection(T)) : Boolean

    List(T)::includesAll(c2 : List(T)) : Boolean

removeAll

    List(T)::removeAll(elements : Collection(T)) : Void

    List(T)::removeAll(elements : List(T)) : Void

Little incoherence is that at the same time some other operations don't have such additions

product

    List(T)::product(c2: Collection(T2)) : Set(Tuple(first: T, second: T2))

union

    List(T)::union (s : List(T)) : List(T)

And the main question is why specializations for every operation which works with collection were introduced.

Looks like that stems from the fact that List  type does not inherit Collection type  (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=418958#c9). To me this is very inconsistently and simply not correct.

User will always be forced to define two counterparts in every simple case. For example:

   helper Collection(Real)::meanValue() : Real { ... }

   helper List(Real)::meanValue() : Real { ... }

or 

   helper meanValue(in c: Collection(Real)) : Real { ... }

   helper meanValue(in c : List(Real)) : Real { ... }

Besides, let's imagine that QVT 1.x will introduce, say, mutable queue or bidirectional map or something similar. Follows List type experience this new type also won't inherit Collection type. Then the new operation which accepts a certain type will appear in the existing types, like:

    List(T)::excludesAll(c2 : Queue(T)) : Boolean

Of course dedicated root like MutableCollection (which all other mutable collections will inherit) might be introduced but that is also problematic design.

Yet another point is that operations 'excludesAll()/includesAll()/product()' in Collection-rooted types don't accept List instance without explicit conversion. That is also awkward.

Last point is that this issue introduces 'asList' operation for Collection type which implicitly refers that List might inherit Collection type:

    Collection(T)::asList(T) : List(T)

Regards,

  Sergey.

_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/qvto-dev

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3684/7068 - Release Date: 02/06/14

_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/qvto-dev