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
Von: qvto-dev-bounces@xxxxxxxxxxx [mailto:qvto-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Sergey Boyko
Gesendet: Mittwoch, 5. Februar 2014 17:36
An: QVTOML developer mailing list
Betreff: Re: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2
Hi Ed,
QVT 1.2 Revision Task Force
Issue 13988: Capitalization of leading characters in multiword operation names.
I consider this proposal is very sensible. It should not be closed. It's always good to use CamelCase to increase readability. All existing namings like 'deepclone' should be marked as 'deprecated'.
Issue 15215: QVT1.1: Add an operation Model::getURI().
Useful proposal. Should not be closed. To me suitable name for such function is 'Model::getResourceURI()'. I do not share described doubts. In most mentioned questionable cases an empty string should be returned as the result of the
call.
QVT 1.2 Revision Task Force
Issue 13265: Page 65, Notation Section 8.2.1.3 Module.
Proposed resolution is incorrect. The context specification here is very confusing, it should be removed. Configuration property is (unlike the contextual property) defined in context of transformation.
Thus Revised Text should be:
Properties that are configuration properties are declared using the
configuration qualifier keyword.
configuration property MAX_SIZE : String;
Issue 14620: QVT 1.1 Inappropriate ListLiteralExp inheritance (Correction to issue 12375 resolution).
Proposed resolution is incorrect. ListLiteralExp correctly extends CollectionLiteralExp type thus allowing to reuse existing CollectionLiteralPart.
Issue 15978: clause 8.3.1.4 Exception needs to document the taxonomy of Exception types in QVT1.1.
To me StringException is redundant and useless. Consider Java exception hierarchy, even Throwable declares Throwable(String).
Really, base class in hierarchy does not have to be abstract.
So (as it was proposed) String message attribute for Exception is right decision. And dedicated StringException is not needed and should be removed.
Issue 19146: Specify List::reject and other iterations.
Operation 'deepclone()' should be spelled as 'deepClone()'.
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.
Issue 19178: What happens when an exception is thrown by an exception handler.
Absolutely unrelated topic. QVTo takes Java approach so nested exception is allowed and processed normally.
Link to C++ is misinterpreted. Nested exceptions certainly are allowed and widely used in C++.
It seems that proposed resolution implied SEH (Structured Exception Handling, SEH) exceptions instead of typed C++. SEH comes from OS and was designed for C. MSDN says "Structured exception handling works with C and C++ source files. However,
it is not specifically designed for C++." So they are definitely not an example for QVTo.
The issue should be closed (not resolved).
QVT 1.2 Revision Task Force
Issue 12526: Errors and anomalies in QVT 1.0 07-07-08 ZIP imperativeocl.ecore.
Property 'CatchExp.exceptionVariableName' is incorrect. There should be 'CatchExp.exceptionVariable : Variable {composes} [0..1]' in order to preserve type also.
Changing multiplicity of 'CatchExp.exception' from '*' to '+' is incorrect. Multiplicity for 'CatchExp.exception' should be '*' (so that empty 'except' statement is handled).
Issue 15977: abstract/concrete syntax for try/catch in clauses 8.2.2.13 & 8.2.2.14 lacks support for retrieving the exception caught.
First, revised text for 'CatchExp.exceptionVariable' should be:
In 8.2.2.14 CatchExp and the QVT 1.1 models add
exceptionVariable : Variable [0..1]
Second, revised text incorrectly alters description for 'CatchExp.exception'. It should be:
In 8.2.2.14 CatchExp and the QVT 1.1 models change
exception: Type [*] {ordered}
Third, EBNF for '<except>' is incorrect. It should be:
<except> ::= 'except' '(' <except_type_list_opt> ')' <expression_block>
<except> ::= 'except' '(' IDENTIFIER ':' <type_list> ')' <expression_block>
<except_type_list_opt> -> <type_list>
<except_type_list_opt> ::= %empty
