2009/2/26 Jim Deville <jdeville@microsof= t.com>

> -----Original Message-----
> From: brian ford [mailto:brixen@gm= ail.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 For= d <brixen@gmail.com> wrote: > > On Feb 24, 9:17=A0pm, Yehuda Katz <wyc...@gmail.com> wrote:
> >> I'm also in favor of discussing this, but all I hear so f= ar in
> opposition is
> >> vague FUD... no specific examples of problems that could be c= aused.
> It would
> >> be a lot easier to have a lively discussion about specific co= ncerns,
> and I'd
> >> love to have it!
> >> -- Yehuda
> >>
>
>
>

> We're talking about a fairly small num= ber 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<= br> > (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<= br> > 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 switc= h this if you are thinking that way). What happens in the following case?
module Merb::String
=A0def foo
=A0 =A0bar
=A0end

=A0def bar
=A0 =A0"bar"
=A0End
end

module Foo::String
=A0def bar
=A0 =A0"foo"
=A0end
end

use Foo::String =3D> String
use Merb::String =3D> String

"a".foo

Does that return "foo", since Foo::String should be searched firs= t? Or does that return "bar", since foo is defined in Merb::Strin= g, and normal resolution would look in Merb::String. My gut tells me that i= t should return "foo", since, in essence, Foo::String#bar "o= verrides" Merb::String#bar. However, that could be confusing. If we do= return "foo", and Foo::String#bar overrides Merb::String#bar, th= en 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
>
> >