OpenEuphoria

Re: Revised Namespace Proposal

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

David Cuny writes:

> Was there a reason you didn't consider 
> allowing multiple files to share the
> same namespace? ie:
>
>   include win32a.ew as win32lib
>   include win32b.ew as win32lib
>   include win32c.ew as win32lib
>
> That would allow large files (like Win32Lib) to be 
> broken up into several smaller files, and still conform 
> to the rules you laid out.

I considered it, but I couldn't see enough advantage to it.
I know you'd like to split Win32Lib.ew into several
separate files, yet somehow group those files together
under the same banner so they can still somehow 
act like one file.

I see a superficial way of allowing this, and 
a deeper way. Neither seems worth it to me.

Superficially, it would be possible to let many files have the
same namespace qualifier, with no error issued. 
Users could write several include statements, 
as you've done above, and then refer to *all* 
Win32Lib-related symbols as win32lib.xxx. 
That would (sort of) hide the
names of the individual Win32Lib files in case
files are removed or new files are added in
the future. It would mean that a namespace
qualifier in the symbol table would refer to a *list*
of files, not one file. Globals would have to be unique
within a list of files. Presumably a
file could belong to many different lists at 
various points during the compile. This is 
messy to implement. It also means the reader
of the code would have to search through many
different source files when he wanted to
locate the source code for a qualified symbol.
The way that you would code the individual
files would not change. You would still have
to create many new global symbols, polluting
the global namespace.
 
A deeper way of grouping files would
bind them more tightly, 
knocking down the barriers between them.
i.e. they could access the local symbols
of files (in the group) that were included earlier, 
without those files having to declare lots of globals.
The existence of a group would 
not be declared within the files themselves. 
It would be created by the user who lists a bunch of
include-as (or include-into as Derek prefers)
statements. This could get very complicated.
Euphoria compiles an included file when it first sees it,
then ignores subsequent includes of the
same file (this will change in 2.3 so that the namespace
qualifier can be assigned, but we still won't recompile
anything).
Euphoria may have already read in and compiled
aaa.e, then bbb.e, as separate files, and made decisions
about which global symbols bbb.e is supposed to access.
Now you come along with a couple of include-as
statements and you expect that the intermediate code for 
bbb.e must be changed retroactively, so it will 
pick up local symbols in aaa.e that were 
ignored when bbb.e was compiled.

What are you gaining from the added complexity 
in the language manual and the implementation?
You are avoiding the introduction of new global
symbols, but we now have a way to resolve any
global conflict. Conversely, you may also be 
missing useful opportunities to *hide* locals within
one file from access by all the other files in the group.

I'm just guessing here.
Maybe you had some other idea in mind.

We could add your idea, or something like it,
in the future, but I'd like to go ahead and implement
the basic (not Basic!) stuff first.

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