Revised Namespace Proposal
- Posted by Robert Craig <rds at RapidEuphoria.com> Jul 05, 2001
- 466 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