OpenEuphoria

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

• Posted by CChris <christian.cuvier at agric?lture.g?uv.fr> Oct 17, 2007
• 836 views

Matt Lewis wrote:
> 
> CChris wrote:
> > 
> > I do not see how, within your framework, an application is protected from a
> > new non interface global identifier popping in a lib's newer version and
> > clashing
> > with an existing symbol in the application. Could you explain how it does?
> 
> OK, I think I didn't make clear exactly which clashes it will prevent.  It
> will prevent any namespace conflicts from happening within the third party
> libraries.  Code that uses the different libraries will still have to
> disambiguate which symbols they wish to use.  This can be easily done
> with namespaces.  The assumption is that the third party libraries do
> not use symbols in places where they are not directly or indirectly included.
>  
> > More generally, I'd like to see a precise documentation of the new working
> > of
> > namespaces you are suggesting. It would be much better than just exhibiting
> > a dozen of contrivedly simple test files, however relevant and useful they
> > may
> > be.
> 
> Here's a shot at it:
> 
> Terms:
> include directly: When one file (f1) includes another file (f2), f1 is
>     said to include f2 directly
> include indirectly:  A file (fx) is said to be included indirectly into 
>     another file (f1) when there is a series of direct includes linking
>     f1 and fx (e.g., f1->f2->...->fx)
> included symbol: A symbol is said to be included into a file if it is
>     a global symbol that has been either directly or indirectly included
>     by the file
> 
> When the parser encounters a symbol that could resolve to multiple global
> symbols, the parser will attempt to use included symbols over non-included
> symbols.  Since the author included a file that exported a symbol with
> the name being used, it is reasonable to assume that the desired symbol
> is the one that was included.
> 
> If a namespace identifier is used, symbols in the file with the declared
> namespace are checked for first.  If none exist, then the parser will
> attempt to use symbols included by the namespaced file.  If multiple
> included symbols match, then a compile error occurs.  To use these symbols,
> additional namespaces must be used for the respective files.
> 
> If a non-included symbol is used, a warning will be generated.
> 

<snipped/>

Consider the following:

-- 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

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.

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.

CChris