[
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
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