1. Re: More Namespace
- Posted by nieuwen at XS4ALL.NL
Sep 28, 1999
> 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.
It would still be legal, just add this line to foo.e
include bar.ex
Visa versa, this would make foo.e compile correctly as it should. Plus, you make
clear foo.e
isn't a solid isolated part of code, but integrated with bar.ex
However, the above is still bad practice, is my opinion. Just a little less
worse, than what they
are already doing. But, by all means, why not:
-- foo.ex
integer ERR_FILE
global procedude set_err_file (integer i)
ERR_FILE = i
end procedure
--------------
Which is what they should have done. The example you mention (irregardless of
the fact how
many programs use it), is not an example of loading library components, its an
old-fashioned,
"include this code here" - type of cut & paste thing. In my eyes, it's bad
practise. For some
time I used it as well, but the fact alone that it won't compile (test by
ex.exe) without errors
makes this a very bad method. Currently, we are forced to use it in some places
(such as in
my BotMatch library, where the bots use lots of identifers and routines that
they haven't
included.) But, now I think of it, having it include 'botmatch.e' again would
solve it wiht the
current edition, and with the namespace suggestions I've done here as well.
Fixing such a program for the future is trivial.
> 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"...
No, global means accesable outside of its own namespace. And it is accesable
*everywhere* but each include file, does need to specify it *wants* to use it.
Fixing this is trivial as well. Just add the include statement on top of the
program.
Result: library will suddenly compile right as well. (which isn't true now for
the programs that
would be 'broken' .. they woudl only compile right when you do ex.exe
yourprogram.ex
rather than ex.exe mylib.e)
> 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.
Much less, I can think of very litle programs that would actually be broken.
Win32lib is certainly not one of them.
And adding the include statement, is a very small effort. For the whole
contribution page (and
archive), this would apply to 10 maybe 15 programs out of the around 200-300
entries (my
guess), of each all of these 10 to 15 programs would be fixed by adding the
include file of the
file they use. The fact that the file A is including file B would, following my
rules, not mean, file
B can't include A. If it want's to use the routines from A is *has* to include
it in the future.
This is such a trivial fix for so few programs.
> So, instead of changing the scope rules of "global" identifiers, I would
> propose a new scope identifier: "public".
Hmm, although public would sound better, I don't want any include file I use to
mess with the
global junkjard. I would want them all to only be applied to those include files
that actually
include them.
> 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.
No, that's the point, They currenlty do NOT work. Not together at least. You
can't use Neil,
Win32lib, graphics.e, Font.e together. And we're too lazy to alter them all to
work together
by renaming or prefixing. This would make it work. None of the libraries I've
mentioned here,
would be broken, why ? Because they consist of only one include file. This only
applied to
libraries and programs that have multiple include files, and declare some global
stuff, later on
used by an include file they include. How many are that ? Are it any libraries ?
Or just
programs ? How fairly easy is it to fix it ?
Considering all that, I still vote for modularization of the 'global' namespace.
If my explenation is vague (which for some is prolly true), go read some docs
about the
namespace in Java, Modula2, Oberon, Icon ... or read about namespace in OOP. And
you'll
find the precize same rules.
Ralf Nieuwenhuijsen
[[ Email ]]
nieuwen at xs4all.nl
ralf_n at email.com
[[ I-Seek-You ]]
UIN: 9389920
[[ The Elevator ]]
http://www.xs4all.nl/~nieuwen
