OpenEuphoria

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

• Posted by Pete Lomax <petelomax at blueyonde?.co?uk> Oct 18, 2007
• 843 views

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.
I see no practical reason to do this. Matt arrived at the same conclusion as me
on this, quite independently, and only after that decision did I point out the
same effect in my priority tables.
http://www.openeuphoria.org/EUforum/m17071.html

> If there are siblings, then yes, throw an error.> 
> 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.
In fact I consider this a necessary evil, hopefully sufficiently rare not to be
a significant problem (also covered in the above link). Making something similar
happen with subincludes basically doubles the probability, for no apparent gain.
> Or because an earlier
> version of lib.e was defining the right n, and the inherited namespaces made
> the transition to current version seamless.
> 
> CChris

Pete