1. Re: More Namespace
You have my vote! globals remain wide global... it's clear English (and
french too).
let's have another keyword 'public', 'export', 'share'... to control the
scope.
... just for fun: have you seen how namespaces are handled in tcl?
I didn't play with it, but they have a lot of functions like 'namespace
children ...',
'namespace export', 'namespace forget', namespace parent' ....
Riwal Raude
rauder at thmulti.com
> -----Original Message-----
> From: Boehme, Gabriel [SMTP:gboehme at POSTOFFICE.MUSICLAND.COM]
> Sent: Monday, September 27, 1999 9:18 PM
> To: EUPHORIA at LISTSERV.MUOHIO.EDU
> Subject: 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
> ----------
