Hi Ed,
Although I like
very much the new approach in the reflective branch, I am not sure we should
merge it with HEAD in this release. Even if we make all tests green and provide patches for QVTO we won't have enough time to get the feedback from
our users/downstream projects to check that the new version is stable. Since it
is quite a big amount of changed
code, we (and consequently the downstream projects) are as well at risk of overlooking something while reviewing...
As you have mentioned it is challenging to get all this by the
API freeze to avoid a major increment next year, so let's see what we will
have by M5 and M6...
Regards,
- Alex.
From:
mdt-ocl.dev-bounces@xxxxxxxxxxx [mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx] On
Behalf Of Ed Willink Sent: Tuesday, January 19, 2010 8:29
PM To: MDT OCL mailing list Subject: [mdt-ocl.dev] Re:
Reflective Library progress
Hi Alex
Getting all this ready for M5/6 is certainly
challenging, but unless we do a major increment next year too, it's almost now
or never. That is why I have reorganised my plans to put as much time in before
M6 as possible and to fudge the editors etc as examples a bit later for M7 with
QVTd deferred again.
The 'phase 2' in the analyzer may merge forward into
a 'phase 3' the remaining major API activity; revising the Environments to
support nested environments in the style that QVTd parsing
exploits.
Constructive reviews, particularly of APIs will be very
helpful. We cannot easily change them later, so let's try to get them
right.
Minor contributions of tests of operations are differently
helpful. Laurent has done many of these identifying a frightening number of
problems in the 1.3.0 behaviour. A fair number of Laurent's results have changed
as a result of OCL resolutions on invalid and null. So a review of all the new
GenericEvaluatxxxx tests would be useful.
However it will be helpful to
defer long philosophical discussions about subtle invalid handling till M7/M8.
Such discussions are important but time consuming. The requisite bug fixes/OMG
issues should not affect the API framework and should be localised in a library
entry or operation class.
I do not expect QVTo to track these changes, so
we must provide a high degree of compatibility withy patches for QVTo where
compatibility is not 100%. However if Sergey likes the look of OCL.oclstdlib and
feels motivated to develop QVTo.oclstdlib immediately we could put less effort
into patches.
Regards
Ed
On 19/01/2010 14:47, Alexander Igdalov wrote:
Ed,
I could do tests/reviews. I am hoping to
have a closer look at what has to be done in the analyzer and let you
know if I could help with it in the middle of next week.
As regards the branch, I liked very much the
implementation of the model-driven library approach you did there. However, I
am not sure it can substitute the old codebase in Helios. Even if it becomes
stable before M6 (API freeze) we should remember about our downstream
projects... I wouldn't merge it with HEAD after M5 unless we provide patches
for QVTO, etc...
Ed, how would you estimate the time needed to make
the branch stable (by 'stable' I mean a stable interim state, e.g. with phase1
only)? Moreover, do you think it makes sense to have a stable but a
logically unfinished engine in this release with
pending breaking changes in the next release?
Regards,
- Alex.
Hi Alex
Yes. In so far as possible
everything that could be defined by an XXX.oclstdlib should be, so that just
by changing to YYY.oclstdlib you get a different configuration of behaviour.
The most important change is for lookup to search the generic library rather
than the Ecore/UML library.
Everything in the analysis field is part of
'phase 2' though I'm beginning to suspect that 'phase 1' may stall without
doing 'phase 2' anyway since 'def' constraints must be added to the library by
the analyzer.
How much time do you have available?
Small amounts
of time could help with tests/reviews.
More substantial time could help
with perhaps 'phase 2'.
Beware: the branch is my development area. It
is not equivalent in quality to committed code. There is much still to
do.
Ed
On 19/01/2010 13:41,
Alexander Igdalov wrote:
Hi Ed,
Thanks for informing me.
I am now merging my patch for collections conformance to OclAny with the
Reflective Library branch. As I see it, there is conformance information in
the OCL.oclstdlib file, i.e. it is mentioned there that Collections conform
to OclAny. Still this information is not used in
AbstractTypeChecker.getRelationShip() and etc. Are you planning to update
the type checker so that it would use the library model rather than perform
by-hand conformance resolution like in getRelationship methods?
Cheers,
- Alex.
-----Original Message-----
From: Ed Willink [mailto:ed@xxxxxxxxxxxxx]
Sent: Tuesday, January 19, 2010 4:23 PM
To: Alexander Igdalov
Subject: Reflective Library progress
Hi Alex
The UML tests now 'work' as well; 116 failures rather than 400.
I've added Status.txt at the foot of o.e.o to remind myself (tell you) what
needs to be done.
Ed
|