OpenEuphoria

Re: EuCOM : Attn Matt : String Return Value

• Posted by CChris <christian.cuvier at agr?culture.gou?.fr> Oct 09, 2007
• 724 views

Matt Lewis wrote:
> 
> Pete Lomax wrote:
> > 
> > Matt Lewis wrote:
> > > 
> > > Actually, namespaces will be inherited (and are inherited, for code at the
> > > head of the svn repository) in the next release.  I typically run this 
> > > code, which is probably why I haven't noticed the bug.
> > 
> > Cool. How did you solve that in the end? In Positive I devised a set of
> > priority
> > tables, which is quite simple really but harder to explain, eg:
> > 
> > -- fileno  desc       parents	 priorities
> > --   1	   inc7 	{}	{2,1,1,1,1,1}
> > --   2	     eric	{1}	{2,4,3,3,3,3}
> > --   3	       bob	{2}	{2,4,6,5}
> 
> <snip>
> 
> My technique is a bit different.  I don't worry about priorities.  Just the
> 'lineage' of each file.  Basically, I record who got included by whom.
> Then, when doing a symbol lookup, if there are multiple matching global
> symbols, I have to do some work.
> 
> If no namespace identifier is used:
> 
> I detect if a symbol is within or without the current file's include
> tree.  If there is only one symbol from the include tree, and one or more
> from without, then the one from within is selected.  This resolution will,
> IMHO, solve 95% of the possible namespace conflicts with 3rd party libs.
> 
> If multiple symbols from within are identified, then an error results.  
> 
> If no symbols from within are identified, and multiple from without, an
> error results
> 
> Now, when a namespace identifier is used:
> 
> If a symbol is not within the file (as specified by the namespace identifier),
> 
> *or its include tree* then it is ignored.  If multiple symbols are found,
> then an error results.  
> 
> This could, in theory, break some existing code, but given the dearth of 
> namespacing in today's code base, I doubt that many would be affected. 
> I suppose it is this situation which led you to the priority scheme, and
> which might be useful in this case.
> 
> I suppose that giving preference to a symbol in the namespaced file (as
> opposed to files included by that file) would also work to solve the 
> dilemma.  It would be similar to having local symbols overriding globals
> from other files.  If the user really needed to use the nested symbol,
> then he could include whatever file it was and give it its own 
> namespace.  A corner case, to be sure, but not inconceivable.
> 
> Matt

Does the include tree also contain the direct ancestors? If not, there are some
issues with this scheme, which is quite common:

-- file1.e
include third.e
global integer n_also_in_third
n_also_in_third=n_init() -- ok, this g.s. shadows anything in third.e
include file2.e
--...

-- in file2.e
integer my_var
my_var=n_also_in_third 
-- could produec an error, while   
-- file1.e::n_also_in_third is obviously being targeted

As the name suggests, n_also_in_third is also a global symbol defined in
third.e.
I'd consider it a problem if this isn't properly handled.

CChris