--000e0cd177ce79564c0463d6da27 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Agreed that it should be LIFO, in order to be consistent with existing Ruby structures. 2009/2/26 Jim Deville <jdeville / microsoft.com> > > > > -----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 > > > > > > > > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 --000e0cd177ce79564c0463d6da27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Agreed that it should be LIFO, in order to be consistent with existing Rubytructures.<br><br><div class="gmail_quote">2009/2/26 Jim Deville <span dir="ltr"><jdeville / microsoft.com></span><br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br> <br> > -----Original Message-----<br> > From: brian ford [mailto:_____###1###_____]<br> > Sent: Thursday, February 26, 2009 9:21 AM<br> > To: ruby-core / ruby-lang.org<br> > Subject: [ruby-core:22548] Re: YASNP (Yet Another Selector Namespace<br> > Proposal)<br> ><br> </div><div class="Ih2E3d">> On Wed, Feb 25, 2009 at 9:23 AM, Brian Ford <brixen / gmail.com> wrote:<br> > > On Feb 24, 9:17 ¨Âí¬ Ùåèõäá Ëáôú ¦ìô»¼á èòåæ½¢íáéìôïº÷ùã®®®Àçíáéì®ãïí¢¾÷ùã®®®Àçíáéì®ãïí¼¯á¾¦çô÷òïô庼âò¾ > >> I'm also in favor of discussing this, but all I hear so far in<br> > opposition is<br> > >> vague FUD... no specific examples of problems that could be caused.<br> > It would<br> > >> be a lot easier to have a lively discussion about specific concerns,<br> > and I'd<br> > >> love to have it!<br> > >> -- Yehuda<br> > >><br> ><br> ><br> ><br> </div><div class="Ih2E3d">> We're talking about a fairly small number of core classes and an even<br> > smaller number of methods that are likely to clash. And selector<br> > 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<br> > likely modified in some way. You add your Merb::String#foo method that<br> > also calls your Merb::String#bar method and someone else wants to use<br> > your Merb::String#foo but a different #bar.<br> ><br> <br> </div>This is actually another important case to consider. We've statedhat 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?<br> <br> module Merb::String<br> ¨Âåæ æïï¼âò ¨Âáò¼âò¾ ¨Âîä¼âò¾ <br> ¨Âåæ âáò¼âò quot;bar"<br> ¨Âîä¼âò¾ end<br> <br> module Foo::String<br> ¨Âåæ âáò¼âò quot;foo"<br> ¨Âîä¼âò¾ end<br> <br> use Foo::String => String<br> use Merb::String => String<br> <br> "a".foo<br> <br> <br> 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 doeturn "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."<br> <font color="#888888"><br> JD<br> </font><div><div></div><div class="Wj3C7c"><br> > The case now is flat, no boxes. SNs add these boxes in a way that will<br> > surely lead to more complexity than checking whether the method you<br> > define clashes with existing methods you use on other libraries. Or<br> > when integrating a library, doing the same check. Libraries do not<br> > suddenly agglutinate somewhere in space. People write them and use<br> > them. Class names can clash, method names can clash. The core lib is a<br> > public pool. Put some dye in so you can see if someone is pissing in<br> > it.<br> ><br> > Frankly, it is worrisome to me that more people are not concerned<br> > about this proposal.<br> ><br> > Brian<br> ><br> > ><br> <br> <br> </div></div></blockquote></div><br><br clear="all"><br>-- <br>Yehuda Katz<br>Developer | Engine Yard<br>(ph) 718.877.1325<br> --000e0cd177ce79564c0463d6da27--