OpenEuphoria

RE: another look at namespaces

• Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Jul 11, 2003
• 655 views

> From: Derek Parnell [mailto:ddparnell at bigpond.com]

> From: "Matt Lewis" <matthewwalkerlewis at yahoo.com>

> > Aha!  I think I've figured this out (in the Eu source code).  I have
> > automatic resolution working using the Eu 2.4 source.  I should have
> > something releasable by this weekend.  (I'm currently porting my 2.3
> > modifications over to 2.4.)
> > 
> > The modifications solve the alice/bob/chris/diane problem.  
> > It was actually pretty simple.  Here's what it does.  
> 
> The 'it' here is your modification, right, and not current 
> Euphoria behavior?

Yes, I meant that once I started thinking about how to implement the desired
behavior, it was pretty straightforward.

> >If you try to reference a global
> > symbol without namespaces, and the symbol exists in more 
> than one file, it
> > will attempt to resolve the identity of the symbol based on 
> the 'include
> > paths' of the symbols.  If there is one [and only one] 
> global symbol in the
> > include path, then that symbol is used.  An include path is 
> defined as files
> > either included directly by a file, or indirectly included 
> by files included
> > by the file.
> 
> Please find a new term other than 'include path' because it 
> took me a few readings of this to realize that your were NOT 
> talking about EUINC environment symbol or similar.

Yes, I've been uncomfortable with that, too, just haven't come up with
anything yet.

> It seems that you are describing a heirarchical 'tree' of 
> file references; have I got that right?
> 
> So the net effect is that ambiguotity is resolved by not 
> looking into files that the file that needs resolution has no 
> knowledge of.

Correct.  The net effect is that whenever you include any third party code,
it should not cause any namespace collision that would require you to edit
any of the third party code.

> Does this also cater for the situation where a file is 
> attempting to reference a global that is declared in its 
> enclosing file.
> 
>  -- erin.e --
>  global atom xyz
>  include bob.e
>  include diane.e
>  . . .
>  
>  -- alice.e --
>  global sequence xyz
>  . . .
>  
>  -- diane.e --
>  . . .
>    if xyz then ...
> 
> In this case, will diane resolve to the 'xyz' in erin or in alice?

In this case, it will not resolve--you'll get a namespace identifier
required error.  Since diane.e doesn't include erin.e or alice.e, it can't
tell which symbol you want.

> --------------
> Here is a another scenario. Hows does this work?
> 
> > Assume:
> > 
>   -- alice.e
>   global sequence name
>   name = "Alice"
>   
>   -- bob.e
>   include alice.e
>   global integer x
>   x = 1
>   global procedure bob_name()
>   printf(1,"Bob says name = \"%s\"\n",{name})
>   end procedure
>   
>   -- chris.e
>   global sequence name
>   ? x  -- ok, this is dumb, but shows that normal
>        -- Eu resolution is still in effect
>   name = "Chris"
>   
>   -- diane.e
>   include chris.e
>   global procedure diane_name()
>   printf(1,"Diane says name = \"%s\"\n",{name})
>   end procedure
>   
>   -- erin.ex
>   global sequence name name = "erin"
>   include bob.e
>   include diane.e
>   include alice.e as a
>   include chris.e as c
>   bob_name()
>   diane_name()
>   printf(1,"Erin says name = \"%s\"\n",{name})
>   printf(1,"a:name = \"%s\" c:name = \"%s\"\n",{a:name,c:name})

The output is this:

1
Bob says name = "Alice"
Diane says name = "Chris"
Erin says name = "erin"
a:name = "Alice" c:name = "Chris"

A symbol in the current file still takes precedent over one in another file.

Matt Lewis