Re: Revised Namespace Proposal
Robert Craig wrote:
> 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
Just my point of view about the possible simplest solution
(I repeate my old mail to list and add the basic part
of my private mail to Robert ) :
If there is no name conflict, there is no any problem. No ?
So, *interpreter* must see on situation, only if there
*is* the **concrete** conflict in the ***new*** program.
Suppose, I use library1.e and library2.e
-------prog1.ex
include library1.e
include library2.e
integer My
My=1
-------end prog1.ex
Run prog1.ex under Eu 2.3 control 
See warning message:
"Symbol My is defined as global in library1.e, rename yours new one
or use that old one as a.My"
"Symbol My is defined as global in library2.e, rename yours new one
or use that old one as b.My"
You can choice, rename new variable or use the old good symbol under
recommended simplest syntax.
Explanation of the notation char.My is very clear
a -- this is the first conflict of My symbols in the *new* program and in
library1.e
b -- this is the second conflict of My symbols in the *new* program and in
library2.e
c -- this is the next and so on.
I don't know, maybe this variant is well known and
an old one, but I like it.
I don't like the *superglobal* variant of automated
main-fail priority.
Global is global. No ?
Then.
a -- this is prefix for the global name space of library1.e
b -- this is prefix for the global name space of library2.e
a then b -- this is just alphabetic order of comparison,
when compare() is used.
So, for name spaces, there is no need to enter new
commands or keywords into Eu.
And this *order* just the same as libraries are included.
*Order* of including is important to define prefixes.
You can create file:
-----my_names.e
include win32lib.ew -- prefix A -- these are just comments
include misc.xyz -- prefix B -- to remember prefixes
include misc.abc -- prefix C
include misc.abc.xyz -- prefix D
----- end of file
Then :
--- my_new_1.exw
include my_names.e
integer My
My=1
A.My=1000
B.My=2000
C.My=3000
sequence S
S={My, A.My,B.My,C.My}
? S
---- end of file
Delimiter '.' is the most convenient due to it exists
in Eu just now.
You see, separate global names may be implemented
without any new keywords and delimiters and without
change of 'global' keyword definition in docs.
Nobody needs to relearn Eu. New syntax is simplest.
But, Rob, only you can see the whole of situation ...
Best regards,
Igor Kachan
kinz at peterlink.ru
|
Not Categorized, Please Help
|
|
