[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: HA: [mdt-ocl.dev] Compatibility Support
|
Hi All,
Let's make our final decision on this subject since it is
the last problem that prevents us from committing changes to the
repository.
AFAIU, the majority prefers variant A. In the
light of this, I would like to transform the "A vs B" question to "If A is
chosen, are there any strong objections to that?"
Cheers,
Alex.
Ed,
Please find my
comments inline.
Cheers,
Alex.
-----Original Message-----
From:
mdt-ocl.dev-bounces@xxxxxxxxxxx [mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx]
On Behalf Of Ed Willink
Sent: Wednesday, July 15, 2009 2:18 PM
To: MDT OCL
mailing list
Subject: Re: HA: [mdt-ocl.dev] Compatibility Support
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 mean : My preference for variant A is also
based on the fact that the MDT OCL implementation deviates from the 2.0
standard, e.g. like in case with OclInvalid/invalid confusion. This is why when
choosing A or B we should also take into consideration such deviations (not only
changes in the specification draft).
I also say that ideal backwards
compatibility is when clients switch to the newer version of a component without
any effort. If OCL clients will be forced to rewrite their extending grammars,
change their metamodels or find out that the methods they used to
invoke/override are no longer available - then the new version is incompatible.
This is another consideration why I choose approach A.
>> 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.
Now it's my turn not to understand you;-)
Are you saying you would leave this problem as is? Or are you proposing any
workaround?
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.
QVTO also extends the OCL grammar, GMF XPand extends QVTO grammar. I have
seen some newsgroup post where a client also wants to extend it.
>> 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.
Generally, yes. But this example was to
reveal that variant A automatically solves problems like this, on the contrary,
in B it requires thorough thinking. Moreover, this incompatibility issue
requires yet another preference setting and requires support of the previous
behaviour which is hardly deduced from the OCL perspective.
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.
Yes and no. Yes, I think that 1.4.0 should
be just a maintenance version of 1.3.x in Helios. IMO the main activity
about it should be keeping dependencies on EMF, UML2 and Orbit updated and
checking that the tests do not fail.
No, I don't think that the sole purpose of
1.4.0 is to provide a slightly more confidence inspiring name. For me, it's goal
is to provide a working copy of MDT OCL 1.3.x for Helios because 1.3.3 itself
will not work with the newer dependencies.
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>
>
>
_______________________________________________
mdt-ocl.dev
mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
