Re: Roadmap for 4.0: Other / 2

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

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
smile
> 
> Matt

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

Search



Quick Links

User menu

Not signed in.

Misc Menu