Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2 : Issue 19146: Specify List::reject and other iterations.
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. 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.

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


Back to the top