From: MonkeeSage <MonkeeSage@...>
Date: 2007-12-28T03:09:58+09:00
Subject: Re: Matz says namespaces are too hard to implement - why?

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:
>
> > What about this example, based on your code:
>
> > require 'namespaces'
> > namespace :foo, %{
> >    class Array
> >      def each
> >        # do something new
> >      end
> >    end
> >    p Array.new.collect
> > }
>
> > 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; so if you define Array#index to return "foo", then any
methods called within that namespace will use the modified
Array#index. And that's just where it gets hairy -- causing extra
lookups (at best, one; more likely, several) for every vcall, to
determine if we're in a namespace. (Someone correct me if I've not
followed the thread right.)

> in method_missing, a la (but mind overriding $1 and fixing up
> exception backtraces):
>
> def method_missing(method, *rest)
>      if method.to_s =~ /^mynamespace_(.*)/
>        send($1, *rest)
>     else
>      super
>    end
> end
>
> I would also believe that with type inference, namespacing should be
> able to make code go *faster*, not slower.  When you do namespace
> lookups, you can do early resolution of calls more easily, as you can
> find the method being available through the namespace and short
> circuit.    (I have no idea if you're doing inference in JRuby - are
> you?)
>
> > See the above example; if you only want namespaces so that within a
> > given block of code method calls to where you want them to, that's
> > simpler to implement. But it breaks some amount of consistency you might
> > expect. It seems like if selector namespacing is useful (which I'm
> > unsure of) it would only be generally useful if it could also affect
> > calls further down the chain. Maybe I'm wrong?
>
> You're expecting consistency at a different level than me, at least.
>
> > At some point you have to be able to say "this code is being
> > namespaced". If you want to do that at runtime, then either you need to
> > modify already-parsed code (which won't work across libraries or calls)
> > or you need every invocation to check for namespaces. If you want to do
> > that at parse/compile time you need a pragma or keyword, and you still
> > can't do it across libraries or calls without installing a namespace
> > check for every invocation.
>
> I think the appropriate point in time is compile time; not being able
> to modify name spaces at run time may be a tolerable cost.  The point
> of name spaces, as I see them, is to avoid name conflicts while still
> retaining "nice" names; while it might be fun to be able to play with
> them at runtime, ones that are restricted to compile time may be
> better than not having name spaces at all.
>
> I'm still on the fence about how useful they are at all - use of plain
> prefixing to create an explicit namespace might be as useful as adding
> implicit ones, and all of this might only be useful in connection with
> adding some sort of protocol (interface definition) support.
>
> Eivind.

Regards,
Jordan