[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[qvto-dev] Project synchronization
|
Hi Horacio, Adolfo
I've just been building Horacio's latest GitHub code and encountering a
little difficulty.
It doesn't build against master or M4. M3 has trivial @NonNull issues.
M2 is needed.
The problem is that I have evolved the mutation 'API' to support code
generated execution:
That is: Type.createInstance(), Property.initValue() have changed.
For these particular methods I should have provided delegating methods
and deprecation. Will rectify for M5.
More generally, evolution of Xtext grammars or the Pivot model tends to
require a bidirectional compatibility, so that old calls to A delegate
to the new A, but also so that new calls to A somehow call old
derivations of the old A. This is difficult and messy, if not actually
impossible. The effort in maintaining the mess is greater than migrating
to the new code in the first place.
Expecting your code to adapt instantly to OCL, QVTd master is clearly
unrealistic.
I suggest that we endeavour to synchronize code as soon as practical
after each milestone release, so today Horacio's QVTd code should using
an OCL branch corresponding to the Kepler_M4_Tools tag and QVTd
corresponding to the Kepler_M4 tag.
Before each OCL, QVTd milestone, I'll check for any missing deprecated
delegations that preserve compatibility. I'll look to remove deprecated
delegation one milestone later.
We'll need to see if there is anything that we can do to improve
Xtext/EMF auto-generated code stability, since once this code is
promoted from examples any changes will be a public API challenge rather
than an informal difficulty for the QVT teams.
Regards
Ed
