From: Jim Deville <jdeville@...>
Date: 2009-02-27T03:43:25+09:00
Subject: [ruby-core:22552] Re: YASNP (Yet Another Selector Namespace 	Proposal)



> -----Original Message-----
> From: brian ford [mailto:brixen@gmail.com]
> Sent: Thursday, February 26, 2009 9:21 AM
> To: ruby-core@ruby-lang.org
> Subject: [ruby-core:22548] Re: YASNP (Yet Another Selector Namespace
> Proposal)
> 
> On Wed, Feb 25, 2009 at 9:23 AM, Brian Ford <brixen@gmail.com> wrote:
> > On Feb 24, 9:17�pm, Yehuda Katz <wyc...@gmail.com> wrote:
> >> I'm also in favor of discussing this, but all I hear so far in
> opposition is
> >> vague FUD... no specific examples of problems that could be caused.
> It would
> >> be a lot easier to have a lively discussion about specific concerns,
> and I'd
> >> love to have it!
> >> -- Yehuda
> >>
> 
> 
> 
> We're talking about a fairly small number of core classes and an even
> smaller number of methods that are likely to clash. And selector
> namespaces don't really change the clashing, they put it in boxes
> (your boxes are my fences Jim) that later will need to be used and
> likely modified in some way. You add your Merb::String#foo method that
> also calls your Merb::String#bar method and someone else wants to use
> your Merb::String#foo but a different #bar.
> 

This is actually another important case to consider. We've stated that namespaces will be FIFO (but there is discussion about LIFO, so switch this if you are thinking that way). What happens in the following case?

module Merb::String
  def foo
    bar
  end

  def bar
    "bar"
  End
end

module Foo::String
  def bar
    "foo"
  end
end

use Foo::String => String
use Merb::String => String

"a".foo


Does that return "foo", since Foo::String should be searched first? Or does that return "bar", since foo is defined in Merb::String, and normal resolution would look in Merb::String. My gut tells me that it should return "foo", since, in essence, Foo::String#bar "overrides" Merb::String#bar. However, that could be confusing. If we do return "foo", and Foo::String#bar overrides Merb::String#bar, then I think SNs should be resolved LIFO, so that it is conceptually similar to monkeypatching, and the last one in "wins."

JD

> The case now is flat, no boxes. SNs add these boxes in a way that will
> surely lead to more complexity than checking whether the method you
> define clashes with existing methods you use on other libraries. Or
> when integrating a library, doing the same check. Libraries do not
> suddenly agglutinate somewhere in space. People write them and use
> them. Class names can clash, method names can clash. The core lib is a
> public pool. Put some dye in so you can see if someone is pissing in
> it.
> 
> Frankly, it is worrisome to me that more people are not concerned
> about this proposal.
> 
> Brian
> 
> >