Re: HA: [mdt-ocl.dev] Compatibility Support

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi Alex

Alexander Igdalov wrote:
> Hi Ed,
>
> My preferences are based on the fact that there are deviations between the standards and deviations of the current implementation from these standards. Another idea is that backwards compatibility ideally requires no changes to be done on the client's side. This is true for the internal API such as Java source code, metamodels and grammar extension. For instance you say:
>   
I'm not sure what you're trying to say here.
> > I see absolutely no need for multiple parsers; all the syntax changes look upward compatible for legal programs; only error messages may differ.
> >     
>
> a) How are you going to deal with invalid and OclInvalid confusion?
>   
The confusion is entirely in the OCL specification, where the wrong word 
is frequently used. There is no real problem for an implementation 
working out what was meant.

invalid/null is more serious. I think that there is a very sensible 
definition in which invalid is bottom and null is nearly-bottom. I've 
requested Mariano to send me an Appendix A source so that I can mark 
this up. For the most part there would be no change, except that we 
could define null = null and null = 'xx' sensibly.
> b) How are you going to support both LPG 1.1 and LPG 2.0 in case we decide to use LPG 2.0?
>
>   
It's mostly a tooling issue. The *.g files become *.gi and generate 
remarkably similar Java class files that use a different run-time. The 
only people affected are those who implement derived grammars. Since the 
ability to include grammars is recent, I suspect that myself and Afolfo 
may be the only people who do it and we're prepared to rewrite.
> > I am now happy to regard the lack of 2.0 consistency of OclAny for collections as a bug fixed in 2.2.
> >     
>
> It might look like a bug for OCL because OclAny operations were not defined on Collections in OCL 2.0. IOW, the expression 'collection->oclIsUndefined()' could not be compiled in OCL 2.0, however, in OCL 2.2 this becomes a legal construction. In QVTO this is an backwards incompatibility issue. This is because QVTO defines '->' accessor as a special xcollect shorthand in case the arrow accessor is applied to collections with a non-collection operation. In QVTO this example it was equivalent to 'collection->xcollect(oclIsUndefined())' because there was no operation oclIsUndefined() for collections. This is why in QVTO 'collection->oclIsUndefined()'  has always been a valid construction. However, with OCL 2.0 it would return a Collection of Booleans, with OCL 2.2 - a single Boolean value.
>
> This is just an example of a problem which requires knowledge beyond OCL to be correctly fixed. With B) each bug will be subject to such analysis and a source of potential problems. Moreover, variant B will probably force clients to change their calls/extensions to the internal API.
>
>   
I have mixed feelings about QVTo 1.0. Clearly we should try to support 
any OCL extension, but only within reason.

The list of approved QVTo FTF and RTF resolutions shows that the QVTo 
specification has many problems of its own.

Any evolving language that extends another commits itself to 
non-conflicting extension. QVTo has gone dangerously close
to modifying OCL. When OCL changes/extends, this is QVTo's not OCL's 
problem.

It is probably worth considering how a QVTo tool will assist its users 
when they migrate from QVT 1.0 + OCL 2.0
to QVT 1.1 + OCL 2.2. MDT-OCL can then provide some assistance for this 
problem.

Suppose that QVT 1.x were to specify OCL 2.2 except some irregularity, 
then MDT-OCL must not prohibit that irregularity. This cannot sensibly 
be achieved by e.g. M2M QVTo cointinuing to use MDT OCL 1.x and 
reimplementing all the 2.x stuff. Eventually M2M QVTo will want to use 
the latest MDT OCL with an ability to tailor an irregularity.

I appreciate that irregularities are a pain, but that is what extending 
languages are going to demand.
> > With respect to A) I'm unclear what functionality 1.4.0 will provide. If there is to be a discontinued branch, why not discontinue at 1.3.0 rather than 1.4.0 or 1.5.0.
> >     
>
> Our course of action is to implement the newest OCL standard. But we must give clients a chance to smoothly upgrade to it. This is why we proceed supporting 1.3-compatible OCL in Helios. We just give clients extra 1-2 years to switch to 2.0.0.
>
>   
If the sole purpose of 1.4.0 is to provide a slightly more confidence 
inspiring name than 1.3.3 for Helios then I have no problem with someone 
doing that. I just don't have time to contribute to any problems that 
arise as a result. If the intention is to offer more than maintenance 
functionality in 3.3 please elaborate.

I think we should proceed with OCL 2.2 as far as we can understand it on 
MDT-OCL 2.0.0 and address any real compatibility issues as they arise.

> Cheers,
> Alex.
>
>
> ________________________________________
> От: mdt-ocl.dev-bounces@xxxxxxxxxxx [mdt-ocl.dev-bounces@xxxxxxxxxxx] от имени Ed Willink [ed@xxxxxxxxxxxxx]
> Отправлено: 13 июля 2009 г. 22:43
> Кому: MDT OCL mailing list
> Тема: Re: [mdt-ocl.dev] Compatibility Support
>
> Hi
>
> I think we're taking this 2.0/2.2 support too seriously.
>
> After reviewing at the changes, I see very little change:
>
> 2.0 and 2.2 share a serious lack of detailed definition requiring
> implementation telepathy.
> 2.2 provides some clarifications and some contradictions.
> 2.2 adds a few clearly distinct upward compatible enhancements.
> 2.2 removes a few really useless concepts
>
> There is not sufficient difference to regard them as significantly
> different specifications.
> OCL 2.0 is not sufficiently definitive to  be worth preserving. We are
> not dealing with
> major historical changes such as Java 1.3/1.4/1.5.
>
> MDL 1.3.0 has already moved beyond OCL 2.0 anticipating/submitting many
> OCL 2.2 changes.
>
> I am now happy to regard the lack of 2.0 consistency of OclAny for
> collections as a bug fixed in 2.2.
>
> For QVT, I see no need to fix on 2.0, after all QVT 1.0 is hardly a
> definitive specification.
>
> I see no point in providing more support for 2.0 than a few warnings if
> someone chooses
> to request 2.0 syntax compliance.
>
> So I'm firmly backing B) because I see very little to duplicate or
> discard. I see absolutely no
> need for multiple parsers; all the syntax changes look upward compatible
> for legal programs;
> only error messages may differ.
>
> With respect to A) I'm unclear what functionality 1.4.0 will provide. If
> there is to be a discontinued
> branch, why not discontinue at 1.3.0 rather than 1.4.0 or 1.5.0. I think
> the plugin naming issues
> are likely to be very difficult for consumers. I can see users of a
> multi-project dependency getting
> 1.4.0 plugins from one project and 2.0.0 plugins from another and
> forever having to make sure that
> they select the correct Java import; which would be correct? Choosing
> the correct OclExpression
> is already awkward. Resolving a 4 four way choice could be really bad,
> particularly with 2.0.0 supporting
> 2.2 and 1.4.0 supporting 2.0; hardly obvious.
>
> The A) policy requires new plugins for each new specification flavour; a
> steadily increasing problem.
>
> The B) policy has a single set of plugins with variation points. These
> variation points support extensibility
> allowing derived languages to make their own choices.
>
> I wrote elsewhere that the variation points should be controlled by a
> map of behaviours in the root environment.
> So I construct a default environment and get default 2.2 compliance. I
> use a different constructor to select
> an alternate (e.g. strict 2.2) menu of behaviours. I use map puts to
> create my own custom language.
> Parser code handling qualified navigation names can test the
> 'has_qualified_navigation_names'
> behaviour to decide whether to issue a warning for usage of pre 2.2
> behaviour. Standard library
> construction code can test the 'library_has_primitive_toString'  to
> decide whether the library
> should support the 2.2 toString methods. Most variation points will be
> resolved by an if or two
> at relevant parts of the code.
>
> Perhaps the most prolific changes are to the standard library, where we
> have a clear requirement to
> support extensibility for QVTo.
>
>     Regards
>
>        Ed Willink
>
> Alexander Igdalov wrote:
>   
> > Hi Team,
> >
> > After analysing the new standard draft we must now decide how exactly we are going to support both OCL 2.2 and compatibility with the previous implementation. I see two options:
> >
> > A. Make a separate set of plugins per each implementation. Evolving this idea, we can now make a new branch of OCL plugins called 'OCL_2_0_support' (a better name is welcome). Thus, in Helios, we would build both 1.4.0 (from the branch) and 2.0.0 plugins (from HEAD).
> > + It is clear how to do it. We can start right away.
> > + It is easy. All we need to do is being accurate with versions in manifest files and change labels/ids in the UI examples so that the implemenations would be distinguishable in the UI. We will also have some releng issues.
> > + It is a finite task. Once we do it, ideally we can forget about OCL 1.4.0 and focus on the new standard. Practically, we will have to care about things like updating dependencies, running builds, etc. Perhaps, we will have to fix some of the must-do items for the release train - like introducing capabilities. But the effort will be minimal.
> > + It gives more freedom for the new implementation. For instance, there would be no problem to drop some public method or change some other API whether internal or external. We introduce the changes in HEAD while the branch is always backwards compatible.
> > + Simplicity and clarity of code. The code will not contain numerous if-clauses checking whether it is this or that standard and then doing different actions per each case.
> > + Little effort to eventually drop 1.4.0+ support; just to exclude the corresponding plugins/features from the release train (e.g. after the next two releases).
> > - We will double the amount of plugins. For those who run both implementations in a single Eclipse memory requirements will also increase (but not dramatically I suppose)
> > - Releng activities will probably become more complicated. More headache for the releng guy (i.e. me).
> >
> > B. Combine both standards in a single set of plugins.
> > + Probably the total amount of code (responsible for what we have by now) will not increase significantly.
> > + Releng would be the same as before.
> > - Unclear how to do it. In each case we will have to invent some workaround - add new metamodels, combine two parsers and possibly two LPG implementations, create numerous if-clauses in code. Moreover, what would be the condition of these if-clauses? IOW, what will we check to distinguish the standards: a system property, some flag in the environment, some external context, preference page, etc.? I feel it would be difficult.
> > - It is an infinite task (at least until the 1.4.0+ support is discontinued). One will always have to keep the previous implementation in mind when fixing a bug. Each bug fix will need to answer the question "will it be backwards compatible?" and decide how to make it backwards compatible.
> > - (Backwards compatibility) bugs. Since this approach is more complicated it will probably produce more bugs, including compatibility issues.
> > - Less freedom for the new implementation. If we change some internal API the clients may experience problems. We will always have to keep this in mind deciding what to do in each case.
> > - Code polluted with numerous checks and branches supporting two standards.
> > - Considerable effort to eventually drop 1.4.0+ support.
> >
> > Considering these pros and cons of each approach, I vote for variant A.
> >
> > Cheers,
> > Alex._______________________________________________
> > mdt-ocl.dev mailing list
> > mdt-ocl.dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
> >
> >
> >
> >     
>
>
> _______________________________________________
> mdt-ocl.dev mailing list
> mdt-ocl.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
>
> _______________________________________________
> mdt-ocl.dev mailing list
> mdt-ocl.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
>
>
>