[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [qvto-dev] Oustanding discussion for QVT 1.3 Ballot 3
|
Hi
(We've just gone quorate with 4 out of 7 YESes for Ballot 1, 6 simple
issues.)
On 14/10/2015 12:40, Ed Willink wrote:
Access vs extends. Transformation are classes. Just think of what
Java does. If you import a class you can optionally instantiate them,
if you want to extend you have to explicitly do it in the concrete
syntax. In java, it's clearly access by default. Although in Java you
can only extend one class (which makes the extend by default stupid),
I don't see any convincing argument about why the specification
should say the opposite for QVTo transformations. Although both bring
interesting points of view, I sympathize with Christopher's arguments
rather than Sergey's ones.
This is QVT13-58. We mostly agree that QVT should specify 'access'. We
mostly worry that this breaks Eclipse QVTo. If it breaks SmartQVT too,
then I can declare 'extends' as de facto practice, rather than Eclipse
convenience.
I have to go with what I perceive to be right for the QVT specification.
'access' seems to be the intuitively safe default. My original analysis
focussed on the dangers of 'extends' in deep scenarios.
Christopher reports real user confusion with an 'extends' default.
If this is a problem for Eclipse QVTo, then some compatibility
launch/preference/... option will have to be provided. Perhaps a
transitional quick-fix might provide 'extends' where a blank setting now
fails. At any rate a warning can be issued for blank access/extends.
Regards
Ed Willink
