OpenEuphoria

Revised Namespace Proposal

• Posted by Robert Craig <rds at RapidEuphoria.com> Jul 05, 2001
• 587 views

I read through the suggestions that people put forward
last week regarding the namespace issue, and 
I've come up with a fairly minimal solution 
based on what various people seemed to agree on.

Thanks to all who contributed. I'm not going to try to 
attach people's names to the various ideas, 
since I'd probably get it wrong.

Scope of Symbols: 
  
  private: symbols visible within one routine     

  local:   symbols visible within one file  
              (after the point of declaration)

  global:  symbols declared with "global" keyword, 
                they are visible within the whole program  
              (after the point of declaration)
  
 New Rules:
 
 1. A local symbol will override any global symbol 
     with the same name. This is currently an error. Everybody seems
    to agree that this would be a good thing. It will eliminate many
    conflicts. A (suppressible) warning will be issued.
  
 2. You can have multiple global symbols with the same name declared
    in different files. This is currently an error. It will no longer
    be an error, and no warning will be issued either, since you can't
    harm yourself until you actually reference one of the symbols.
    
    If there are two or more globals defined in other earlier files 
    you'll get an error unless you qualify the name.
    e.g.
           graphics:x += 1
           win32lib:foo()
    
    The ':' symbol is probably a better choice than '.' , in case we
    ever get into OOP, structures etc.
 
    A namespace qualifier is created by adding a name to an include
    statement, e.g.
    
           include mygraphics.e as graphics
           include win32lib.ew as win32lib
     
    I'll also allow quotes around included file names, 
    in case someone wants to include a name with blanks in it, e.g.

          include "Program Files\\myfile.e"

    Otherwise the quotes aren't needed,
    and blank (whitespace) terminates the file name.
  
    The scope of a namespace qualifier is the file in which it
    is created. By specifying a namespace qualifier, you can 
    later say explicitly which file contains a particular 
    global symbol you are referencing. Other than creating a 
    qualifier symbol, this type of include statement is just the 
    same as other include statements.
    
    A qualifier may only be used to refer to a *global* symbol.
    Local symbols can't be accessed from other files.
    
    Within the scope of a local symbol x, or private symbol x, 
    you can also reference a global x as long as you qualify it, 
    e.g.  myfile:x
    
 Symbol Lookup Algorithm:
    
    Qualified Symbol -  namespace:x
    
    1. It must match a previously-declared global symbol in the specified 
       namespace (included file), otherwise it's an error. 
        
    Unqualified Symbol -  x
    
    1. Look for x as a private variable in the current routine (if any).
       Private vars in a routine are all unique.
    
    2. Look for x as a local or global symbol declared earlier in the current 
       file. local/global symbols in a file are all unique.
    
    3. Look for x as a global symbol declared earlier in another file.
       If there is more than one such x, it's an error since you didn't
       qualify it.
 
This is what I'm prepared to implement for 2.3.
It may be possible to refine this in future releases
once we gain some experience with it.

I know that this doesn't do much to help with breaking up
Win32Lib.ew, since you'll still get a large number of 
new globals "polluting" the user's namespace, but 
the user can now resolve any global vs. global conflicts 
that might occur, and the more common global vs. local 
conflicts will be resolved automatically.

If anyone can see a simple way to improve 
on this proposal that won't take too much time, 
please post it to this list.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com