OpenEuphoria

More Namespace (was: little question once again)

• Posted by nieuwen at XS4ALL.NL Sep 27, 1999
• 333 views

NameSpace
=========

The current namespace suggestion of prefixing with the include file: it will not
work with the
present programs and librariesnot ? Because they still conflict! Irregardless of
the fact that
you're program is capable of specifying the include he meant. I suggest, that
the base of fixing
the namespace problem is by getting rid of that one huge global namespace. It
*is* that
simple.

"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.

Now, the point-syntax may be a solution, but routine names in Euphoria are
already very
long. I think it would create almost unusable long identifier names.

Plus, it isn't really needed:: no program has to use both the normal graphics
routines and Neil
at the same time, for example. And then there is always routine-id. The biggest
namespace
issue at the moment is that Euphoria halts your program rather than letting the
identifier being
redefined. The second biggest problem *would* be: Once routines are overloaded
once and
the original routines are 'included' *again* what should Euphoria do ? Answer:
Overload
them again. Implementation-wise this would mean, for some 'colliding' routine
names the
interpreter has to know which of the two include files was included last *in
this current
namespace* .. so, for the interpreter, a situation as:

include a
 z = special_libfunction (x)
include b
 z = special_libfunction (x)
include a
 z = special_libfunction (x)

The first call would be to the function from include file 'a', the second from
include file 'b' and
the third again from include file 'a'. Assuming both files contain a function
called
special_libfunction ()

This would already *fix* the problem, however, we might, lazy as we are, forget
to include a
number of files that we _do_ use, but usually are already included and part of
the namespace.
This is why I suggest modular-namespace. So, in short, the example above shows
how, in my
eyes, Euphoria should handle 'overloading' .. but I suggest routines from an
include library not
specifically included by that part of the program should generate an error. This
will force a
programmer to specify all the include files that he uses in that particular file
( a library or
program component), with the result that possible side-effects of changing the
order of
include files in the main program or any library loaded earlier are simply not
possible.

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.




Ralf Nieuwenhuijsen

[[ Email ]]
    nieuwen at xs4all.nl
    ralf_n at email.com

[[ I-Seek-You ]]
   UIN: 9389920

[[ The Elevator ]]
    http://www.xs4all.nl/~nieuwen