OpenEuphoria

Re: symbol resolution (was:EuCOM : Attn Matt : String Return Value)

• Posted by CChris <christian.cuvier at a?riculture?gouv.fr> Oct 18, 2007
• 834 views

Matt Lewis wrote:
> 
> CChris wrote:
> > 
> > 
> > Consider the following:
> }}}
<eucode>
> -- app.exw
> include lib.e as lib
> ?lib:n
> 
> -- lib.e
> include sublib.e as sublib
> 
> -- sublib.e
> global integer n
> include subsublib.e as subsublib
> 
> -- subsublib.e
> global integer n
> </eucode>
{{{

> > The sublib and subsublin namespaces are optional.
> > 
> > Now some questions:
> > 1/ There are two different n defined below lib.e, and none in lib.e.
> > Your docs imply that lib:n should cause an error. I don't think so: 
> > the closest up should mask the other symbols below it. If there are
> > siblings, then yes, throw an error.
> 
> I think this is a reasonable conclusion, but I have some reservations.  What
> 
> about the case where they aren't direct descendants?  We'd need to be able 
> to calculate the "minimum include distance" in this case.  At that point,
> if something unrelated gets rearranged in some file (includes change, etc)
> you'll end up with a bug that's very difficult to prevent, and probably
> hard to catch.  The alternative, where if some conflicting symbol were 
> added, would throw an immediate error, and you'd know that you needed to
> specify which you wanted.
> 
> For the above reasons, I think I'd stick to only allowing the top-level
> symbol mask included symbols.
>  

I don't think an absolute distance should be used, exactly for these reasons.

However, if there are two or more symbols below the namespaced file, and there
is none in that file, and if one of these symbols is above the others, then the
situation you describe doesn't occur, because one of the symbols is at the root
of a subtree containing all others. In that case, the identifier should resolve
to this symbol. On the contrary, if there is no such root, or if the root doesn't
define the desired identifier, it is an ambiguous condition, and an error has to
be thrown. Rearranging has very little chance to cause a switch between these two
situation, while it can upset anything based on a mere distance calculation.


> > 2/ If lib.e's newer version defines n, which it currently doesn't, then
> > app.exw has a risk of being affected in an unpredictable way, if it is
> > important that sublib:n be accessed, and lib:n was coded out of genericity.
> > Or because an earlier version of lib.e was defining the right n, and 
> > the inherited namespaces made the transition to current version seamless.
> 
> Yes, this is a potential hazard.  This is probably a great reason to be
> able to hide symbols (assuming the author didn't want sublib:n to be
> used in the first place), though it could be that the library author
> still wants both to be visible.  The only reasonable defense against this
> is for the library author to make sure a change such as this is communicated
> to the users.
> 
> I don't really see any alternative, other than not allowing namespaces to
> inherit.  I suspect that this is a very rare situation, and I still
> believe that the benefits outweigh the costs.
> 
> Matt

No problem. It's just that this has to be documented somewhere if it is to be
part of the language.

CChris