namespace tool?

>Hi Group,
>
>Is there a namespace tool that would 'explain' how a namespace was resolved (i.e. which namespace rules were engaged)?
>
>e.g.
>
>    Given:
>
>        Method Picture>>#foo references class Circle
>
>    Doit Action:
>
>        "Please explain resolution of the reference to class Circle"
>
>    Explanation:
>
>           full path = Geometry.Circle
>            derived via 'Graphics' import of 'Geometry'
>            'Graphics' contains class 'Picture'
>
>Not being expert on the Namespace rules, I'm guessing that there are cases when the names rules that were engaged would produce an interesting (and helpful) explanation.
>
>The reason I was is that we've hit a namespace issue(s) in migrating from 7.6 to 7.9.
>
>Ready to dig deeper; and learn more about namespaces. However, thinking possibly there are tool(s) already for such?
>
>Thank you,
>
>Gary P
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>vwnc mailing list
>[hidden email]
>http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>  
>

> Dear Gary,
>    either you get ambiguous references or not.  Breakpointing reference to
> DuplicateBindingsError and looking at the stack to see how you got there
> may be a quickish way to see why e.g. the lookup is seeing two Circles.
>
> If the issue is not so much about duplicates as about how to contrive
> seeing the right things and keeping the wrong things invisible, here are a
> few remarks.
>
> 1) Each namespace can have specific imports (e.g. MyNameSpace.Circle) and
> Generic imports (MyNameSpace.* - everything in that namespace).  At each
> point of import, a specific import will trump the same name from a generic
> import.
>
> 2) Imports can be private or public.  Public imports are also visible to
> any namespace that imports the importer of public ....*.  Private are only
> visible to the importing namespace:  a namespace that imports the importer
> must also itself explicitly import any of the formers private imports that
> the latter namespace also wants to see.
>
> 3) #namesAndBindingsDo: is near enough the top-level of search that you
> can break there and walk down to see how it works.  This debug walk is
> tedious, but that's how I really got to grips with this;  if you can't
> reason out from the documented rules why something is or is not seen, that
> kind of debug may both show the specific cause and make the rules clearer
> to you.
>
> Side-remarks
>
> a) Be aware of package property #namespace, which affects the scope of
> extension methods compiled in that package.
>
> b) If you are porting from a non-NameSpace dialect, loading
> Porting-NameSpaces and putting your code in a FirstFindNameSpace may help.
> (It suppresses DuplicateBindingsError, just binding to the first match
> found in the search:  do not use when not needed.)
>
> c) It is my habit to regard dotted referencing as evidence of need to
> restructure imports or namespaces, use the package property, or revise
> code.  There are exceptions, and times when it legitimately must be
> deferred or discarded, but I think it's a good general rule of coding.
>
>                      HTH
>                            Niall Ross
>
>>Hi Group,
>>
>>Is there a namespace tool that would 'explain' how a namespace was
>>resolved (i.e. which namespace rules were engaged)?
>>
>>e.g.
>>    Given:
>>
>>        Method Picture>>#foo references class Circle
>>
>>    Doit Action:
>>
>>        "Please explain resolution of the reference to class Circle"
>>
>>    Explanation:
>>
>>           full path = Geometry.Circle
>>            derived via 'Graphics' import of 'Geometry'
>>            'Graphics' contains class 'Picture'
>>
>>Not being expert on the Namespace rules, I'm guessing that there are cases
>>when the names rules that were engaged would produce an interesting (and
>>helpful) explanation.
>>
>>The reason I was is that we've hit a namespace issue(s) in migrating from
>>7.6 to 7.9.
>>
>>Ready to dig deeper; and learn more about namespaces. However, thinking
>>possibly there are tool(s) already for such?
>>
>>Thank you,
>>
>>Gary P
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>vwnc mailing list
>>[hidden email]
>>http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>
>
>