|
Hi Adolfo,
Yes, that's a good idea to ask Kenn and Nick (Boldt). I
will write a compiled letter to them if we all agree
on A.
Cheers,
Alex.
Hi Team,
I don't have any strong objection to variant
A.
Maybe, we could ask Kenn to ensure that we are not having any future
problem (releng, or whatever - I'm a newb in this area - ) which we are not
taking into account.
Cheers,
Adolfo.
Alexander Igdalov
escribió:
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
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
|
