On Dec 27, 2007 7:09 PM, MonkeeSage <MonkeeSage / gmail.com> wrote:
> On Dec 27, 11:10 am, Eivind Eklund <eekl... / gmail.com> wrote:
> > On Dec 22, 2007 4:22 PM, Charles Oliver Nutter <charles.nut... / sun.com> wrote:
[... example calling collect from something importing a namespace snipped ...]
> > > The default implementation of Enumerable#collect calls each. Would you
> > > expect collect to see the original each method or the one you've
> > > provided in the namespace?
> >
> > Original each.
> >
> > The way I think about it, importing a namespace is gaining access to a
> > group of methods that you wouldn't otherwise get access to.  You can
> > do namespacing manually by calling all your methods
> > "mynamespace_method" instead of just "method", and checking for this
>
> Well, but that's the trivial case that Charles talked about. The
> practical case would be where all the code called from a given
> selector namespace respects the definitions / constants / variables of
> that namesapce;

My point was that I do not see why this would be any more practical.

I don't know what your usecase is; from my point of view, the idea of
namespaces is to separate the call space for implementations of
different extensions to a set of types (in a more static language,
each type would be a different class; this is less relevant for Ruby),
so that different extensions do not step on each other.

As far as I can tell, there are slightly different tradeoffs between
using lexical scoping (which I propose) and dynamic scoping (which you
propose), with the dynamic scoping enabling some hacks that the
lexical scoping doesn't, and the lexical scoping having the benefits
of ease of understanding and speed of code.

This is the standard tradeoff between lexical and dynamic scoping; in
languages that provide both dynamic and lexical scoping for variables
(Perl, Lisp) my experience is that we end up using about 1000x more
lexical than dynamic scoping, and in languages that only provide
lexical scoping (e.g, Ruby), we easily work around the lack of dynamic
scoping and hardly notice that it isn't there.

If you (or anybody) can show me usecases that show that dynamic
scoping is essential for implementation of namespaces in Ruby, of
course I'm all ears.  So far, it's just seems like the need for
dynamic scoping has been taken as a given, and I personally feel that
dynamic scoping make programs harder to understand than lexical
scoping, and that without compelling usecases it seems more reasonable
to use lexical scoping, which also avoids the speed penalty.

Eivind.