From: Michal Suchanek <hramrach@...>
Date: 2007-12-23T07:18:13+09:00
Subject: Re: Matz says namespaces are too hard to implement - why?

On 22/12/2007, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
> Robert Klemme wrote:
> > 2007/12/22, Stefan Rusterholz <apeiros@gmx.net>:
> >> But I think I begin to see a thought mistake. I guess I have
> >> to think about it a bit :-/
> >
> > Actually that fits well with what I was going to suggest: it seemed to
> > me that you did not have yet fully made up your mind what you want.
> > :-)  I doubt though that a lexical solution would be as useful as a
> > call stack scoped one.
>
> Ditto, though I'm not a fan of selector namespacing yet anyway.
>
> > Also, Charles, maybe implementation implications for lexical scoped
> > changes might be less dramatic but wouldn't they still impose a
> > performance penalty at runtime?  I mean, the issue of checking would
> > not change whether it's dynamically or lexically scoped.  And there
> > must be a penalty because of Ruby's dynamic nature, i.e. since it's
> > not compiled you cannot decide at compile time which version of a
> > method needs to be invoked.  When I think about it it may even make
> > implementation more difficult, because then the set of current methods
> > changes even more (i.e. when you redefine a method in a namespace and
> > invoke that method from another method invoked in that namespace the
> > old definition would apply again; this also imposes the interesting
> > question if recursion with redefined methods is still possible... :-))
> >  A lot of interesting problems to solve. :-)
>
> Yes, lexically scoped namespaces would have the same performance
> implications call-stack scoped namespaces iff they were applied
> dynamically at runtime. If they were applied statically at parse time,
> via a keyword or other syntax, the overhead of checking for a namespace
> would be limited to specific chunks of code:
>
> (assume "namespace" is a keyword)
>
> my_string.rb:
> class StringDecorate
>    def foo
>      "woohoo!"
>    end
> end
>
> foo.rb:
> namespace String => StringDecorate {
>    "".foo # => "woohoo!"
> }
> "".foo # => error
>
> So the idea here is that since namespace is a keyword, at parse or
> compile time everything inside the block would be decorated with
> namespace-checking logic. And more importantly, everything outside the
> block would remain blissfully unaware of namespace checking at all.
>
> But this is still predicated on the idea that lexically-scoped
> namespacing is actually useful.
>

So this is a syntax sugar for something like

#string_decorate.rb
module StringDecorate
def do_foo_with_string str
"woohoo!"
end
end

#foo.rb
require 'string_decorate'

include StringDecorate
extend StringDecorate

do_foo_with_string ""



Now I do not say it's useless to add methods to a class w/o the fear
you would stomp on somebody else's added methods. But it only makes
the code look slightly nicer at the cost of some obfuscation of the
origin of the methods and some performance penalty.
Or is the foo also supposed to be visible in methods called from the block?


The stack scoped namespace then would be roughly quivalent to

class AddBar < SimpleDelegator
def bar
"foobar!"
end
def inspect
"I won't tell you :p"
end
end

do_something_with (AddBar.new foo)

It's dreadfully slow. I tried it when I wanted to add methods to a
Fixnum and found out it does not have a class. Of course, if the
wrapped object is stored somewhere the method does not go away when
do_somethin_with ends.
On the other hand,  it is somewhat consistent. If the method overrides
were on the stack you could get different views of the same object
from different places.

Basically all these things require to store some class and method
indexed hash of overrides somewhere that is searched before the
standard class hierarchy. It requires to do the search multiple times
but is should be like doing the standard lookup 2x or 3x, not the
horrendous slowdown as with the pure ruby delegator.

Thanks

Michal