1. Re: More Namespace
Ralf Nieuwenhuijsen wrote:
>"Global will, from now on, be interpreted as accessible from any file
>that contains an *include* statement with the name of the file."
>
>In other words, modularize namespace and 99% of the problems will be
>solved, or can be easily solved. The same is true for overloading of
>identifiers.
[snip]
>So, in short, two rules, would solve everything:
> - overloading occurs again and again and again when the include
> statement is encountered.
> - only identifiers defined in an include file directly included in the
> current namespace (the current file, ie. a library or program) are
> accessible.
>
>This will, in my eyes, be the most clean approach to handle the namespace
>issue. It makes currently broken programs run, and does not add any new
>construct to the language, and most of all, when you use it, its quite
>intuitive.
I mostly agree with this idea, but there are a few important things it
overlooks. Fortunately, I also have an alternate solution. But before we get
to that, the drawbacks...
First of all, this kind of thing (currently legal) will no longer work:
-- foo.e
global procedure write_err_file(sequence msg)
puts(ERROR_FILE, msg)
end procedure
-- bar.ex
global constant ERROR_FILE = open("foobar.err","w")
include foo.e
write_err_file("Phooey!\n")
Euphoria's current include file rules regarding global identifiers go *both*
ways -- from includer to includee, and vice versa. Now, you might think that
this method of using globals is just silly, but it is used by ed.ex &
syncolor.e, as well as Mark Honnor's dynamic include file method -- just to
name two instances.
Secondly, the word "global" clearly implies an all-encompassing scope. Were
we to suddenly define "global" as
"not-entirely-global-but-something-like-it", more than a few people would be
confused. Kind of like the "move" instruction in Cobol, which really means
"copy"...
Finally, this proposal would break a LOT of code. Now, for me, Euphoria is
just a hobby kind of thing, and it wouldn't kill me too much to change all
my programs to accommodate changes in scope rules. But what about people
developing in Euphoria at their workplaces? Or people who have contributed
hundreds of things in Euphoria and will have to change them all (e.g. David
Cuny)? This would be MUCH more of a headache than we've been led to believe.
So, instead of changing the scope rules of "global" identifiers, I would
propose a new scope identifier: "public".
"public" identifiers would be required to follow the rules laid out by Ralf
N., while the "global" identifiers would work just as they always have.
Now yes, this will still require programmers to go back into all their
programs and include files to change "global" to "public" -- but even if
they don't, the programs and include files WILL STILL WORK! No code will be
"broken" by this change -- a new (and more preferable) alternative will
simply be made available to the programmer.
Anyway, that's my $0.02 worth on this subject...
Gabriel Boehme
----------
"Begin with the possible and move gradually towards the impossible."
Robert Fripp
----------
