Roadmap for 4.0: Other / 2
What would be the purpose and use for the "namespace" projected keword?
I understood that this supplied namespace allows unambiguous access to a global
symbol in the library, thus sparing the library user the need to use an
include...as complete form. A convenience is hardly ever bad to have, granted.
Now there is another issue which doesn't appear to be addressed, and which is,
in a way, the reverse problem:
-- mylib.e
include myutils.e
--
x=my_func()
-- myutils.e
global function my_func()
return 0
end function
my_func() had to be declared global, because it is used in mylib.e. Yet, it is
not intended to be used outside the library, and is not documented in its
interface as a result. And my_func() can hardly be moved to mylib.e for various
reasons, among which cleaner code breakup.
How can I prevent Joe D. User to inadvertently use the function in his app which
includes mylib.e? Knowing that my_func() may well disappear or change name in the
next version of mylib.
If we don't want full fledged packaging, for the sake of simplicity or whatever
(sigh), then at least let's have an extension to global, in the following way:
global to <namespace> function my_func()
The effect of the modified declaration would be that the symbol cannot be
accessed by an unqualified call outside its definition file, but only using the
supplied namespace. <namespace> should notexist as namespace, except if it is
declared in a "namespace <something>" directive in (any ancestor of) the
definition file.
Certainly not better than packaging, since Joe D. User could still use it (but
less inadvertently), and the library writer has to type in a bunch of namespace
qualifiers.
Another variant would be a "restrict my_func() to <namespace>" directive, with
the same semantics. In both cases, it would make sense for the namespace to be a
library namespace.
In a nutshell, Eu lacks nutshells, ie data encapsulation.
Thoughts?
CChris
|
Not Categorized, Please Help
|
|
