[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [mdt-ocl.dev] API changes before the API freeze
|
Thanks Ed,
Concerning 289759, mentioned as applicable to environments,
I hope EcoreEnvironment will remain happy with EPackage.Registry
and it just will be possible to assemble that using your migrated
metamodel registry. Or am I wrong?
It would be good if these kind of changes come ASAP, as receiving them
a couple of weeks before M6 could be fatal for us. Me and Sergey support
QVTo in our spare time as well, so it would be said to spend
most of the cycle on adapting to OCL.
Regards,
/Radeks
On Fri, 27 Nov 2009 21:24:39 +0100, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi Radek
http://wiki.eclipse.org/MDT/OCL/Dev/Areas provides an overview of
activities current and pending.
My approach is to try to create a clean class/object structure similar
to the existing one but that cures problems with OCL compliance and
extensibility (for QVTd and editors). Once a clean structure is in place
much of the original interface can be mapped to the clearer interface,
hopefully avoiding problems for consumers that just use the API in a
simple fashion. Consumers that fight the old interfaces to workaround
limitations are likely to need revision since fighting should no longer
be necessary.
The above certainly applies to the Environments (see Bugs 212120 and
289759).
The library provides a major opportunity for improvement to support
extensibility; primarily for QVTo. I have no time to work on this so I
cannot comment on how this may turn out.
Regards
Ed Willink
radek dvorak wrote:
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
_______________________________________________
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