Re: [mdt-ocl.dev] Compatibility Support

[Ed Willink <ed@xxxxxxxxxxxxx>]

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