Re: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2

[Sergey Boyko <serg.boyko2011@xxxxxxxxx>]

Hi,

On Sat, Feb 8, 2014 at 3:43 PM, Christopher Gerking <christopher.gerking@xxxxxxxxxxxxxxxx> wrote:

Hi

 

If we define

 

Collection::asList() and

Element::clone()

 

isn’t it just the particularity of List that the implementations for both are identical?

Since Element is a base type for all types (including Collection) in type hierarchy so 'List::clone()' is defined for List type by inheritance.

Status of appearance of 'asList()' is somewhat different. 

Ed has mentioned many times that List type is not Collection. Taking that position into account the operation 'List::asList()' is not defined for List type by inheritance. And already having 'List::clone()' yet another completely the same operation 'List::asList()' is explicitly defined specially for List type. Not a clear decision.

Stating that List type conforms to Collection (which position I still adhere) removes the question since 'List::asList()' will be available for List type by inheritance.

 

 

Doesn’t the same argument hold for other collection types like Sequence? It also supports clone() and asSequence(), which are two operations that I would implement identically by just returning self.

Of course 'clone()' for immutable collections does not make any sense (as well as 'asSequence()' for the Sequence type). But as I told such duplication which arises from the evolution of specification is possible and it is the reasonable price for using OO principles in API.

Regards,

  Sergey.

 

 

Sorry if there is something I really don’t understand.

 

 

Regards

Christopher

 

 

 

Von: qvto-dev-bounces@xxxxxxxxxxx [mailto:qvto-dev-bounces@xxxxxxxxxxx] Im Auftrag von Sergey Boyko
Gesendet: Donnerstag, 6. Februar 2014 21:29

An: QVTOML developer mailing list
Betreff: Re: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2

 

Hi,

 

I don't think that cross-version compatibility of script is a real issue. Moreover statement 'list->reject(…)->clone()' is more self self-descriptive. Operation 'clone()' is defined for all Collections. 

Intentional duplication (unlike unintentional when duplicates appear as the result of evolution) is doubtful decision.

 

Regards,

  Sergey.

 

On Wed, Feb 5, 2014 at 9:10 PM, Christopher Gerking <christopher.gerking@xxxxxxxxxxxxxxxx> wrote:

Hi

 

> Operation 'List::asList()' duplicates 'List::clone()'. Duplication always has 'bad smell' and should be avoided to not confusing users. Since both operation are

> really the same then the first should be removed.

 

All other concrete collections support asList(). Thus, it seems only consequent to declare Collection::asList() and redefine it for List. This is especially helpful with respect to your latest fix that changes the return type of List::reject(…) from List to Sequence. Hence, the statement list->reject(…)->asList() is a sensible approach to support different versions of Eclipse QVTo. It requires asList() to be available not only on Sequence, but also on List.

 

 

Regards

Christopher

 

 

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