Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [mdt-ocl.dev] Re: Reflective Library progress
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.

From: Ed Willink [mailto:ed@xxxxxxxxxxxxx]
Sent: Tuesday, January 19, 2010 4:52 PM
To: Alexander Igdalov
Subject: Re: Reflective Library progress

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

Back to the top