OpenEuphoria

Re: Idea for NameSpace-problem

• Posted by MAP <ddhinc at ALA.NET> Apr 22, 1998
• 844 views

In yesterday's post I included some code showing what I'd like to see
done with namespaces. Let me take a minute to reverse myself on one
particular convention I mentioned. I said that in a situation like
this:

global namespace somelib
        atom x
end namespace

that x would be global. After thinking about that some I realized
that that would not serve the purpose I had in mind for doing
namespaces this way, it should be

global namespace somelib
        global atom x
end namespace

to make x visible outside that namespace thru somelib:x.

In David Cuny's post he expressed some trepidation over having
the "end namspace" declare the end of the namespace rather have
it run to the end of the file, and over the nested syntax for
namespaces, like foo:bar:some_func(). My intention for this usage
of namespaces was to provide a method for more than just resolving
library conflicts, but to allow the user a great deal of flexibility
in controling the scope of variables and functions within a program
as well. The result is something like the features of OOP languages
that use classes with public and private portions for controling
which aspects of a group of features are exposed or hidden.
You could do something like:

global namespace widgets
        namespace low_lev_ctrl
                sequence bar
                sequence foo
                global function something_low_level(atom x, atom y)
                        if length(foo) = length(bar) then
                                return (x * y))
                        end if
                        return ((x + length(foo) - length(blah)) * y)
                end function
        end namespace -- low_lev_ctrl
        global namespace windows
                sequence window_list
                global procedure resize(atom handle, integer x, integer y)
                        if handle then
window_list[handle][some_property] =
                                something_low_level(x, y)
                        end if
                end procedure
        end namespace -- windows
        global namespace buttons
                -- various button controls
                .
                .
                .
        end namespace -- buttons
      -- more widgets
        .
        .
        .
end namespace -- widgets

Notice that the namespace low_lev_ctrl was not preceded by global, that
would mean that this namespace is not exported outside the namespace
it resides in. something_low_level() would be accessable only to other
items within the widgets namespace. In addition, the sequences foo and
bar within low_lev_ctrl were not declared global (perhaps a better
keyword
is export) and are not visible outside of low_lev_ctrl at all.
You're prolly wondering "why do this?". Well for small projects I
wouldn't
bother with it at all, it's usually very simple to track dependancies
and side affects without all the extra work in a small program. But in
a large project, especially one that requires maintenance after sitting
around for a while it's not so easy. This method allows you to limit
dependancies and side-affects. You won't be tempted to use
something_low_lev() in other aspects of you programming than within
widgets (which would normally occur in a quick fix situation).
So, if you do away with this procedure or alter it in some fashion,
you have limited the scope of it's possible side-effects to just
the portion of code related to the problem. It makes fixing bugs and
adding new features in future versions a simpler task. And it makes
sure your not tempted to box yourself in with some fix-all function
that may eventually require you to rewrite a major portion of your
code.

Of course, as I said before, this is designed not to break any old
code already existing or force you to use it in a situation you don't
feel it's necessary. For simply resolving lib conflicts you would
just put a namespace at the top of the file and end namespace at the
bottom. (the "end namespace" is also necessary for the situation where
the user wraps an old library inside his/her own program to resolve
conflicts, see yesterdays post for an example of that).

Regards,
Christopher D. Hickman