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

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

IMHO List::asList() is debateable; there is a not very good argument for it, and a nont very good argument against. It is not harmful so I'm not motivated to change it.

(I plan to have a Ballot 4 to retract the bad nested exception resolution. Anything else that MUST change can go in there too.).

It is very important to define clone() as self for collections so that the recursive behaviour of clone/deepclone for mutables is defined.

        Regards

            Ed

On 11/02/2014 09:27, Sergey Boyko wrote:

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

_______________________________________________
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: 3697/7082 - Release Date: 02/10/14