From: Martin DeMello <martindemello@...>
Date: 2009-02-26T04:04:12+09:00
Subject: [ruby-core:22488] Re: YASNP (Yet Another Selector Namespace 	Proposal)

On Wed, Feb 25, 2009 at 10:53 PM, Brian Ford <brixen@gmail.com> wrote:
>
> Apparently my thought experiment on possible misuses is too difficult.
> Here is a concrete alternative exercise. What are the principles for
> using selector namespaces?
>
> When do you put one method in? If one method, why not two? Where are
> the boundaries in a library, framework or application?
>
> The essence of my objection is that you will so cleverly put into a SN
> a method that someone else will want to change.

I'm not seeing your point - selector namespaces aren't a fence to keep
client code out, they're a fence to keep framework code in. Let's say
merb defines String#chars, wrapped neatly within a namespace so that
all the code in merb can make use of it and no code outside merb sees
it. Now as a merb user/extender, if you want to change the way
String#chars behaves within merb, simply reopen the namespace and
change it. All that the SN is preventing is merb's String#chars from
leaking out into the global namespace - in fact, I'd go so far as to
say that it changed monkeypatching from being dynamically scoped to
being lexically scoped, which cannot be other than a good thing.

> Again, there has been no justification for why SNs are *needed* to
> solve the problem presented here. You want to have multiple methods
> with the same name on the same public, common class but with different
> behaviors. There is no justification for why #chars or #camel_case
> *must* have different behaviors.

In fact SNs could fix something that has always bothered me about ruby
- that 'require' introduces dynamically scoped changes to your
environment.

martin:~ $ cat a.rb

class String
  def length
    1
  end
end

martin:~ $ cat b.rb

class B
  def foo
    "hello".length
  end

  def bar
    require 'a.rb'
  end
end

b = B.new
p b.foo
b.bar
p b.foo

martin:~ $ ruby b.rb
5
1

With your code, you know what you are doing; with a framework, you
shouldn't need to worry that 'require' is doing something other than
giving you access to that framework's defined API simply because
*within the context of the framework* it was found convenient to
redefine some core classes.

> You think, "I'm so smart about programming my app, no one will want to
> monkey patch this method." But they will! Just as they have done in
> Ruby for a long time. And when they do, what will that look like? And
> when you try to understand the behavior of some software, you now need
> to look into N different definitions of one method name and determine
> how those interact.

Let them monkeypatch it and be happy. They'll just need to do it
within the namespace.

> Complexity for what benefit? How is this more natural? And it is not
> just in one file. There is no restriction of a class to one file in
> Ruby. Open class gives the ability to build software in layers.

And selector namespaces give the ability to have your code lexically
rather than dynamically scoped.

martin