Re: Matz says namespaces are too hard to implement - why?

On Dec 22, 2007 4:22 PM, Charles Oliver Nutter <[e-mail]> 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
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.