Eivind Eklund wrote:
> On Dec 22, 2007 4:22 PM, Charles Oliver Nutter <charles.nutter / 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
> in method_missing, a la (but mind overriding $1 and fixing up
> exception backtraces):

I was thinking about this a bit more today and I don't see how it's 
particularly useful. If the namespacing is only local to some block or 
other lexical structure...why don't you just call the methods directly? 
What does it gain you?

It seems like namespacing is only "really" useful if you can also have 
namespace changes apply to calls further down the stack. In a lexical 
context, I don't see what it gains you over just calling different methods.

> 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?)

Not...yet :)

>> 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.

Ditto. If they're only lexically scoped to make "nice" names, I don't 
see the benefit. I could see how they might be useful if you wanted to 
run an entire call stack with temporary modifications, but of course 
that's the trickier version.

- Charlie