OpenEuphoria

Re: More Namespace (was: little question once again)

• Posted by nieuwen at XS4ALL.NL Sep 28, 1999
• 426 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!
>
> I don't see how they conflict, unless you mean that, unchanged they still
> conflict.

What I mean is, when using Jiri's font library and Neil together, for example,
they conflict.
This would be solved by my solution.

> This is good thinking as far as it goes, but will cause a problem I will
> mention further down.

This is how OO languages, as well as Modula-2, and many many others look at
scope rules.
The part where a 'component' is included should not alter its global namespace,
if it could
then it has to be a integrated part of the program and writing solid 3rd party
libraries would
be impossible. (like it is now, no way to hide everything, except the
programmer's interface,
without a risk of routine collision, unwanted overloading, etc.)

Euphoria currenlty makes one long program out of all the different parts, and
thereby actually
eliminating the potential of programming seperated and isolated components.

> 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

This will already make a lot of difference.

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

Yes, but not in the same part of the program. Example:

include graphics.e
-- graphics-like stuff

include neil.e
-- neil graphics like stuff

include graphics.e
-- graphics stuff again

Without adding any new construct to the language we've suddenly accomplished
almost the
same, except for the fact that one routine can't use routines from both includes
at the same
time, however this is easily overcome with even a small wrapper, such as:

include graphics.e
 procedure eu_pixel (sequence s, object p)
        pixel (s, p)
 end procedure

include neil.e
 procedure neil_pixel (sequence s, object p)
        pixel (s, p)
 end procedure

Off course, I would only have to wrap one of the two, it is much cleaner this
way.

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

What I mean is, I wouldn't mind adding an argument to the routine_id that lets
you specify
which include file, although, even that is not really needed. The example above
that wraps the
two pixel routines could also be like:

include graphics.e
 constant eu_pixel = routine_id ("pixel")
include neil.e
 constant neil_pixe = routine_id ("pixel")

If only Euphoria wouldn't halt your program when identifers get overloaded.

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

True, but hte multiple pass thing is very untrue actually.
Think about the way Euphoria currently handles with/withouts.
Imagine your prefix would be added. Whenever it sees an include file, it already
makes a list
of identifers within that namespace. Now, all it has to do is add the prefix of
the include file
loaded last. Where are your multiple passes ?

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

No, off course not. Think about Dos32Lib/Win32Lib, by only changing the include
file, you
can have your program run using a completely different mechanism/gui on a
different
platform. Currenlty, we would still be able to do so, however, what happens when
I also use
some other OO library that also defines identifers such as class, etc. ?
Then I would either need to prefix all routine calls (making a conversion to
dos32lib harder)
or, when my rules would be taken over (my rules ? about a dozen languages
include java use
the same modularization. Isolation is the whole point of seperate include
files), it would
automatically work as we meant without having to change anything or any part,
without
messing with prefixes, or routine pointers.

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

If two libraries collide big time, and the above rule is true, you could simple
split your
program up, and make sure the two libraries are not included at the same time in
some
library.

> Thanks for the thought provoking post, Ralf.

Actually, it was how I first assumed it would work. When I started to understand
the one
huge global namespace junkjard, it confused me.

As simerlar as most expect this to work in the beginning:

{ x, y } = location ()

Although, unlike the modularization, this would be a new thing, where the
modularization is
pretty much a logical standard within programming. (except for asm+++++ (I mean
C) and
the like)






Ralf Nieuwenhuijsen

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

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

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