[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] API changes before the API freeze
|
Hi Ed,
Could you please outline incompatible changes in the area of
Environment/library/resolver/type which are of main concern to
QVTO and everyone who extends OCL. I wasn't able to find corresponding
bugzillas.
At least I could make some guess if we will be able to release at all.
Regards,
/Radek
On Fri, 27 Nov 2009 20:24:20 +0100, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi
M6 in mid-March is the API freeze, so we have 4 months left for any
changes that
can be done as part of the major increment to 3.0.0.
Most of the AST/parser stuff is done; just a few trivia to align with
the final
ballot resolution details; assuming that they are voted through.
Migration to
LPG 2 should be pretty easy, stage one is already +1'd subject to LPG in
Orbit.
Stage 2 may be almost ready for review after resubmission.
I'm starting to look at the Environment issues; firstly to migrate the
QVT File/Root/Node
environments across so that EcoreEnvironment and UMLEnvironment don't
have to be
reimplemented in derived Environments and secondly to merge the tryXXX
lookups
and CST lookup arguments to have a clean preferred hierarchy of lookup
methods,
retaining most of the existing methods for probable though not guaranteed
compatibility. Adolfo no doubt remembers what a mess QVTd gets into
trying to
override these methods.
The role of the Environments is well-indicated by the OCL specification.
The role of the extra helper objects is not; reflection; type resolver;
type
util, standard library etc. I think we want to try to have a single
reflection
object owned by the root environment that provides binding-dependent
services,
and a single library mode; that adds as little functionality as possible
to that
provided by an EMF model. Therefore a lot of library/resolver/type
functionality
may need to move to the reflection object.
I can do the Environment changes. We need a volunteer for the
type/library
changes which will need to tackle issues such as making the standard
library a
first class model and making the type inheritance model-driven. With
this in
place the enhancements to the evaluator to support invalid and OclAny
may become
obvious.
If we don't start work on this soon we will lose the opportunity.
For the Model Registry, I am doubtful that I will have time to develop
the
better GUI. However a View-based rather than Property Page-based GUI
need not be
an API breaker, so this can wait. I may therefore submit the Model
Registry soon,
after only a minor API review.
For the editor, there is good news. The three most annoying bugs that
provoked
me to create a private bug-fixed version are fixed in CVS. The IMP
project plan
shows a 1.0 release planned for Helios. To preserve an ability to
enhance editor
APIs next year we might choose to bundle the editor in the examples
feature, put
internal on all package names, or just not export the packages.
Could someone please review
https://bugs.eclipse.org/bugs/show_bug.cgi?id=290654
(one week old)?
Alex: How's the Bug 293605 posting to eclipse.org-committers doing?
Regards
Ed
