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

[Ed Willink <ed@xxxxxxxxxxxxx>]

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