Re: More Namespace (was: little question once again)
On Mon, 27 Sep 1999 18:38:33 +0000, nieuwen at XS4ALL.NL wrote:
>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!
I don't see how they conflict, unless you mean that, unchanged 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."
>
This is good thinking as far as it goes, but will cause a problem I will
mention further down.
>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.
>
As I suggested in another post, my preference is to allow "named" includes
to keep the prefixes short. These might be something of the order of
include foo=foo_this_name_is_to_long_to_easily_use.e
very much like a globally declared constant, which in reality, it is. Now
everything gets prefixed with foo.
>Plus, it isn't really needed:: no program has to use both the normal
>graphics routines and Neil
Many times libraries grow up that are only partially congruent and it is
quite convenient to use routines from multiple libraries.
>at the same time, for example. And then there is always routine-id. The
>biggest namespace
routine-id is what I call a foreign attachment to the language..it violates
the letter and the spirit of the language to allow linking to Windows
routines. I recognize the need, but I would very much not like to read too
many more programs that use it...most confusing.
>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 be an unmitigated disaster(nothing personal :). The interpreter
would have to make multiple passes through the same include for possibly
every shift in library that the programmer wants to use. Ugh! Now, if we
were to extend your original namespace argument by modularizing includes,
the second include of "a" would merely be a switch to a previously parsed
include. I would still prefer the prefix, rather than being dependent on
order of include. I always prefer explicit to implicit measures, but their
is no reason that both approaches cannot be combined.
>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.
I wasn't sure about the last part of your explanation, but this is clear,
and it just doesn't allow enough flexibility without causing huge overhead.
Overloading should only occur in "unnamed includes of the current type".
Named includes should be prefixed.
> - only identifiers defined in an include file directly included in the
current namespace (the
>current file, ie. a library or program) are accessible.
I agree 100% with this one. Includes embedded in includes are a pain, and
should not be allowed unless somebody can come up with a really elegant,
efficient and painless way to deal with them(a form of modularization might
meet this standard). Include libraries should state their dependencies in
the documentation and it should be the job of the programmer to insure that
those other includes are written in and available. With named includes,
include libraries could be programmed in such a way as to pick up the global
name constant that is a prefix for the routines that they need and plug it
into the include. Probably need to think about that one for a little longer.
>
>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
>
Thanks for the thought provoking post, Ralf.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
