Re: Idea for NameSpace-problem
- Posted by MAP <ddhinc at ALA.NET> Apr 21, 1998
- 810 views
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