Re: [mdt-ocl.dev] Patch for https://bugs.eclipse.org/bugs/show_bug.cgi?i

[Axel Uhl <eclipse@xxxxxxxxxxxxxxxxxx>]

Ed,

I just attached a working patch which only adds methods, doesn't change 
existing behavior as long as a ::-prefix isn't used, and performs a 
global lookup if and only if a ::-prefix is used. The solution uses an 
additional global:boolean argument to the ...lookup... operations while 
any existing such ...lookup... operation delegates to the new flavors 
passing false for global. All existing usages of ...lookup... in 
org.eclipse.ocl.* that I found I adjusted to use the PathNameCS.global flag.

With this, what are your remaining concerns regarding other usages? Can 
you check any implications on QVTo?

Thanks and best,
-- Axel

On 3/6/2011 11:11 AM, Ed Willink wrote:
> Hi Axel
>
> Incidentally, the root of the API problem is the List<String> path
> argument. If this was an object such as PathNameCS you could have just
> added an isGlobal field, with the API unchanged. PathNameCS is needed as
> an argument for other purposes, because any lookup using a List<String>
> has no contact with the CST and so cannot generate correct contextual
> diagnostics. I introduced PathNameCS to persist the List<SimpleNameCS> a
> couple of years ago. That had minor ripples on QVTo, but concerned
> solely the creation of the CST. The analysis usage was the next phase,
> and I felt it was just too hard. One of many motivations for the Pivot
> model.
>
> If you're going to devote time to this, and I don't recommend it (I
> regard it as close to impossible) add a duplicate set of useful lookups
> that do something better with the PathNameCS and always leave the
> resolution of ambiguity to the caller. The impossible bit is traversing
> the nested environment hierarchy using the old API yet providing the
> extra argument for the new API. For this I think my horrible but
> pragmatic solution of a "::" special first name is the only viable
> approach.
>
> Ah! another horrible approach. You could maintain a map of List<String>
> to Boolean in the environment, or simpler just a Set<List<String>> for
> which isGlobal isTrue, so that you can lookup the lost global flag.
> List<String> is at least a unique object, and should not have clones
> while still existing at global scope, so this might work.
>
> Regards
>
> Ed
>
>
> On 06/03/2011 09:50, Ed Willink wrote:
> > Hi Axel
> >
> > There are also QVTr and QVTc, which I'm responsible for. They are not
> > in themselves sufficiently useful that they should inhibit an API
> > evolution. But...
> >
> > In developing QVTr and QVTc and after very superficial scanning of
> > QVTo and Acceleo code, I am aware how inextensible the current CST and
> > Environment APIs are. As a result derived code tends to do sneaky
> > interceptions of protected methods, so anything that breaks the
> > precise control flow of any derivable method may break derived code.
> > It's a nightmare. I will almost certainly veto any proposed API change
> > that is not clearly an addition only.
> >
> > Regards
> >
> > Ed
> >
> > On 06/03/2011 09:07, Axel Uhl wrote:
> > > Ed,
> > >
> > > > it is semantically affected. This includes a review of QVTo and Acceleo
> > > > code which will inherit the changed parser grammar.
> > >
> > > are there clients of the concrete syntax tree beyond the analyzers in
> > > the org.eclipse.ocl.* domain?
> > >
> > > I'm currently contemplating adding flavors of the
> > > tryLookupClassifier(...) methods that take an additional
> > > global:boolean flag and have the existing methods delegate to them.
> > > That to me sounds API-compatible, particularly since the global-flag
> > > would always be false unless set by the new ::-prefix.
> > >
> > > Best,
> > > -- Axel
> > > _______________________________________________
> > > mdt-ocl.dev mailing list
> > > mdt-ocl.dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
> > >
> > >
> > > -----
> > > No virus found in this message.
> > > Checked by AVG - www.avg.com
> > > Version: 10.0.1204 / Virus Database: 1435/3484 - Release Date: 03/05/11
> >
> > _______________________________________________
> > mdt-ocl.dev mailing list
> > mdt-ocl.dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
> >
> >
> > -----
> > No virus found in this message.
> > Checked by AVG - www.avg.com
> > Version: 10.0.1204 / Virus Database: 1435/3484 - Release Date: 03/05/11
>
> _______________________________________________
> mdt-ocl.dev mailing list
> mdt-ocl.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev