Re: [qvto-dev] Oustanding discussion for QVT 1.3 Ballot 3

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

On 14/10/2015 11:39, Adolfo Sánchez-Barbudo Herrera wrote:
> Traceability, I've tried not to step in more into traceability issues, 
> because you are already receiving feedback from Christopher which has 
> more experience in real world scenarios. I'll have a look to the 
> related resolutions again, and bring comments. Can you please point 
> out the issues so I don't overlook anyone ?.

http://solitaire.omg.org/browse/QVT13#selectedTab=org.omg.jira.task-forces%3Ataskforce-issues-panel&view=HAS_PROPOSAL

is the 'active' work in progress/pending.

Of these QVT13-23/QVT13-99 (and the QVT13-9/QVT13-22 mergeds) are QVTo 
issues waiting to go in to Ballot 3 this evening.
> 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.

> [NB Apparently, I'm allowed to vote in JIRA for QVT 1.3 ballots. I 
> shouldn't be....]
Perhaps on one page, but you'll get trapped later on.

    Regards

        Ed Willink