--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">&lt;jdeville / microsoft.com&gt;</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>
&gt; -----Original Message-----<br>
&gt; From: brian ford [mailto:_____###1###_____]<br>
&gt; Sent: Thursday, February 26, 2009 9:21 AM<br>
&gt; To: ruby-core / ruby-lang.org<br>
&gt; Subject: [ruby-core:22548] Re: YASNP (Yet Another Selector Namespace<br>
&gt; Proposal)<br>
&gt;<br>
</div><div class="Ih2E3d">&gt; On Wed, Feb 25, 2009 at 9:23 AM, Brian Ford &lt;brixen / gmail.com&gt; wrote:<br>
&gt; &gt; On Feb 24, 9:17     潢㮮㮮ᾦ庼
&gt; &gt;&gt; I&#39;m also in favor of discussing this, but all I hear so far in<br>
&gt; opposition is<br>
&gt; &gt;&gt; vague FUD... no specific examples of problems that could be caused.<br>
&gt; It would<br>
&gt; &gt;&gt; be a lot easier to have a lively discussion about specific concerns,<br>
&gt; and I&#39;d<br>
&gt; &gt;&gt; love to have it!<br>
&gt; &gt;&gt; -- Yehuda<br>
&gt; &gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div><div class="Ih2E3d">&gt; We&#39;re talking about a fairly small number of core classes and an even<br>
&gt; smaller number of methods that are likely to clash. And selector<br>
&gt; namespaces don&#39;t really change the clashing, they put it in boxes<br>
&gt; (your boxes are my fences Jim) that later will need to be used and<br>
&gt; likely modified in some way. You add your Merb::String#foo method that<br>
&gt; also calls your Merb::String#bar method and someone else wants to use<br>
&gt; your Merb::String#foo but a different #bar.<br>
&gt;<br>
<br>
</div>This is actually another important case to consider. We&#39;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&quot;<br>
  
end<br>
<br>
module Foo::String<br>
    quot;foo&quot;<br>
  
end<br>
<br>
use Foo::String =&gt; String<br>
use Merb::String =&gt; String<br>
<br>
&quot;a&quot;.foo<br>
<br>
<br>
Does that return &quot;foo&quot;, since Foo::String should be searched first? Or does that return &quot;bar&quot;, since foo is defined in Merb::String, and normal resolution would look in Merb::String. My gut tells me that it should return &quot;foo&quot;, since, in essence, Foo::String#bar &quot;overrides&quot; Merb::String#bar. However, that could be confusing. If we doeturn &quot;foo&quot;, 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 &quot;wins.&quot;<br>

<font color="#888888"><br>
JD<br>
</font><div><div></div><div class="Wj3C7c"><br>
&gt; The case now is flat, no boxes. SNs add these boxes in a way that will<br>
&gt; surely lead to more complexity than checking whether the method you<br>
&gt; define clashes with existing methods you use on other libraries. Or<br>
&gt; when integrating a library, doing the same check. Libraries do not<br>
&gt; suddenly agglutinate somewhere in space. People write them and use<br>
&gt; them. Class names can clash, method names can clash. The core lib is a<br>
&gt; public pool. Put some dye in so you can see if someone is pissing in<br>
&gt; it.<br>
&gt;<br>
&gt; Frankly, it is worrisome to me that more people are not concerned<br>
&gt; about this proposal.<br>
&gt;<br>
&gt; Brian<br>
&gt;<br>
&gt; &gt;<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--