Re: Idea for NameSpace-problem

new topic     » goto parent     » topic index » view thread      » older message » newer message

Here's my idea on how the namespace concept should be applied:

---------------------------------------------------------------------
namespace foo
        atom a
        integer b
        namespace bar
                atom a
                function afunc (atom a)
                        return a*a
                end function
        end namespace -- bar
        foo:a = 1 -- unneccesary
        a = b -- fine, assumes local namespace
        bar:a = a -- yup
        a = bar:afunc(a) -- that's legal
        a = afunc(a) -- not legal
end namespace -- foo


-- outside the foo namespace they'd be called
foo:a
foo:b
foo:bar:a
foo:bar:foobar()
---------------------------------------------------------------------


for new libraries and programs:
---------------------------------------------------------------------
-- foolib.e
global namespace foolib -- as a convention, (not enforced by compiler)
                        -- the namespace exported should be the name of
                        -- the lib.
                        -- also note that since the namespace is global,
                        -- everything with it is global.
        constant SOME_CONST = 1
        function some_func(atom a)
                return a * a
        end function
end namespace -- foolib

atom someatom -- not visible outside foolib.e
---------------------------------------------------------------------
-- someprog.ex
include "foolib.e"

atom someatom
someatom = foolib:some_func(2)
---------------------------------------------------------------------


for new programs using old (non-namepace) libs:
---------------------------------------------------------------------
-- foolib.e
global constant SOME_CONST = 1
global function some_func(atom a)
        return a * a
end function

constant SOME_OTHER_CONST = 2 -- note that even though this lib is
                                -- wraped in the calling program,
                                -- non-globals are not exported

atom someatom -- not visible outside foolib.e
---------------------------------------------------------------------
-- someprog.ex
namespace foolib -- wrap the old lib into a namespace
        include "foolib.e"
end namespace -- foolib

atom someatom
someatom = foolib:some_func(2)
---------------------------------------------------------------------


I think this method provides a better flexibilty than some of the
others mentioned. lib<underscore>var_name is impractical I think
because underscore is already a legal variable name character...
you can't change that without breaking almost all existing code,
and if you leave it to the compiler to make the distinction it
just adds additional overhead. I don't like the lib<dot>var_name
either because the dot representation is generally used for
structures in most languages. I still hope to see Euphoria
implement structures at some point.
This method should also allow programmers to add a more
object-oriented style to their programs, without forcing the
issue or breaking old code.

Opinions?

Regards,
Christopher D. Hickman

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu