OpenEuphoria

2. Re: This whole namespace thing

• Posted by Kasey <kaeyb at GEOCITIES.COM> Apr 25, 1998
• 790 views

Michael Sabal wrote:
>
> It's nice that the Euphoria community is growing so well that we have to worry
 about conflicting >include files written by the community.  In no other
 language I can think of has the language itself >developed by the users of the
 language.
>
> So here's my humble contribution to this thread.  We don't want to change the
 core of Euphoria any >more than we have to.  Adding namespace would mean
 changing the core, if handled internally as most >people have been suggesting.
 Why not make a consistent format for include files that would prevent
 >conflicts almost entirely.  For example:
>
> -- foobar.e
>
> global constant FOO1 = 1
> global constant FOO2 = 2
> global constant BAR1 = 3
> global constant BAR2 = 4
>
> procedure foo1 (...) -- note that this is a LOCAL procedure
>
> function foo2 (...)
>
> procedure bar1 (...)
>
> procedure bar2 (...)
>
> global function foobar(atom code,sequence data)
>
>   object returnable
>
>   returnable = 0
>
>   if code = FOO1 then
>     foo1(data)
>   elsif code = FOO2 then
>     returnable = foo2(data)
>   elsif code = BAR1 then
>     bar1(data)
>   elsif code = BAR2 then
>     bar2(data)
>   else
>     returnable = -1   -- which could be read as an error message
>
>   return returnable     -- obviously procedures return nothing, so this 0
 would
>                         -- be discarded.
>
> end function
>
> --------
>
>         This would keep the general efficiency of the language by avoiding the
> need for a preprocessor, keep Rob from having to modify the language, and
 solve the
> namespace problem.
>         Of course this presents the two drawbacks of existing code (would
 reverse
>compatibility be possible with the other suggestions?)  and slightly more work
 for the
>programmer (but only in that it forces us to be a little more organized with
 our libraries).
> This also resembles OOP a little, because all procedures/func's would be
 called as part of a
>class: junk = foobar(BAR2,{}) using the tools already available as opposed to a
 dot method.
>         Because of the wild nature of the recent threads on structures and
 OOP, I'm going to
> avoid any further comments on that subject ;)
>
>         NB: for the Christians on the list, I'm interested in any Euphoria
 Bible tools you
>might have (except Bibles, I've already got 12MB worth).
>
> Serving Christ,
> Michael J. Sabal
> mjs at osa.att.ne.jp
> http://home.att.ne.jp/gold/mjs/index.html

        I like this one mostly. Not to far offsomthing I've done myself, though
I had each
 new function add a human readable name to one part of a global list and
their function id
 to the other part. of course they took data structured the same as each
other and thier
outputs were all a conssitant type too (filters for a graphics editing
program I'm working on)

        global funtion blur(sequence image_chunk)
        sequence output,temp ----and  so on
        .....
        return output
        end function

        append (filter_A_list[1],"Standard Blur")--- this is at the top level
of the include file
        append (filter_A_list[2],routine_id("blur"))

of course this  methode doesn't do anything about namespace, but if blur
were not global
and you had a function in the include file such as:

        global funtion do_filter(sequence data, integer f_num)
        return call_func(f_num,data)
        end function

though this would defete one of the purposes of what >I<  was trying to
do (which needs the filter
funcions visible at two includes away so I could shroud my source and
others writing filters could
shroud thier code and yet still get the two to co-operate by meerly
adding include those_filters.e
to and inlude file thats nothing more than alist of includes and is in
turn include in the main prog
that lists all the filters for the user to pick between (using
filter_A_list[1])).
But I digress (way to often way to much ;) ) these are do-able now
solutions that don't break existing
code  or change Euphoria itself.
        Besides unless the euphoria community is gonnna 180 itslef and get
insular and stop sharing code
and ideas it's gonna need to devolpe general guidlines on a lot of code
compatability issues anyway, not
just namespaces.
        Of course we could all just add our intials to all our globals to
(funtion KB_bar()) (just kiddding :)  )

                                Kasey