1. 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
2. Re: Roadmap for 4.0: Other / 2
CChris wrote:
> 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:
> }}}
<eucode>
> -- mylib.e
> include myutils.e
> --
> x=my_func()
>
> -- myutils.e
> global function my_func()
> return 0
> end function
> </eucode>
{{{
>
So, my_func() had to be declared public, but you really do not want it public,
you just wanted to access it from within your library.
What if files with a declared namespace could access any function inside that
namespace, regardless of it's location? That may break code, I am not sure.
Example:
-- myutils.e
namespace mylib
function my_func()
return 0
end function
-- mylib.e
namespace mylib -- notice, same namespace
x = my_func() -- acceptable
global function hello()
puts(1, "hello")
end function
-- prog.ex
include mylib.e
mylib:hello() -- good
mylib:my_func() -- bad, parser error
Now, I really am thinking outside of my understanding of how namespaces work
internally and more specifically name resolution internally. After a few more
tasks are done in the standard library, I really must spend some good, quality
time in the interpreter code.
--
Jeremy Cowgar
http://jeremy.cowgar.com
3. Re: Roadmap for 4.0: Other / 2
CChris wrote:
>
>
> 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
<snip>
> In a nutshell, Eu lacks nutshells, ie data encapsulation.
>
> Thoughts?
Agreed. I think the simplest solution would be to add an import directive,
which works similarly to the include directive, except that globals from
files included by mylib.e do not propagate to files that include mylib.e.
This stops short of a full solution, however, because we might really
want some stuff from myutils.e to be visible to users of mylib.e. In
that case, the simplest solution is probably to introduce another scope,
probably "export" to match the symmetry of "import." Then, any symbol
declared as an export would not propagate through an import directive.
Globals would still be globals.
Matt
4. Re: Roadmap for 4.0: Other / 2
Matt Lewis wrote:
>
> CChris wrote:
> >
> >
> > 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:
> }}}
<eucode>
> -- mylib.e
> include myutils.e
> --
> x=my_func()
>
> -- myutils.e
> global function my_func()
> return 0
> end function
> </eucode>
{{{
>
> <snip>
>
> > In a nutshell, Eu lacks nutshells, ie data encapsulation.
> >
> > Thoughts?
>
> Agreed. I think the simplest solution would be to add an import directive,
> which works similarly to the include directive, except that globals from
> files included by mylib.e do not propagate to files that include mylib.e.
>
> This stops short of a full solution, however, because we might really
> want some stuff from myutils.e to be visible to users of mylib.e. In
> that case, the simplest solution is probably to introduce another scope,
> probably "export" to match the symmetry of "import." Then, any symbol
> declared as an export would not propagate through an import directive.
> Globals would still be globals.
This sounds like an explanation of cricket
http://en.wikipedia.org/wiki/Tea_towel_explanation_of_cricket
Chris
>
> Matt
5. Re: Roadmap for 4.0: Other / 2
ChrisBurch3 wrote:
>
> This sounds like an explanation of cricket
> http://en.wikipedia.org/wiki/Tea_towel_explanation_of_cricket
Perhaps the most sensible thing I've ever read on the topic.
Matt
