From: Yehuda Katz Date: 2009-02-26T03:28:44+09:00 Subject: [ruby-core:22480] Re: YASNP (Yet Another Selector Namespace Proposal) --001636e90729b6d74b0463c26aa6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 2009/2/25 Brian Ford > On Feb 24, 9:17 pm, Yehuda Katz 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 > > > > Seems Google ate my reply to this. > > 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? You put any core extensions that you don't want to automatically expose globally into your namespace. Then you use that namespace in your library. > The essence of my objection is that you will so cleverly put into a SN > a method that someone else will want to change. And? I'm not sure we're talking about the same thing. In the proposal, namespaces are just regular modules. They can be reopened and modified at will, just like normal Ruby. > 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. We can just observe the *reality*. In *reality* Merb, DataMapper, and Rails were all using the same names to mean subtly different things. I included one such example in the OP. The only way to avoid this is a massive coordination effort on the part of every library doing core extensions, which has so far proven unrealistic, even with the relatively small number of popular libraries we have today. > You think, "I'm so smart about programming my app, no one will want to > monkey patch this method." That really has nothing to do with the proposal. People can happily monkey-patch anything they want. > 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. Why? How? You look at the software. There either is or is not a "using" declaration present. If there is not, Ruby behaves as it does today. If there is, it adds some additional behavior. How is this significantly different from the (much more ambiguous) changes that can be made via module inclusion? > 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. What? The proposal lexically scopes the new behavior. It has nothing to do with open classes... > The following applies just as well to engineering software and > designing languages as to building furniture: > http://www.johndilworth.com/95. +1 > > > Brian > > > > > > > On Tue, Feb 24, 2009 at 9:13 PM, Jim Deville > wrote: > > > > > > -----Original Message----- > > > > From: Jim Weirich [mailto:jim.weir...@gmail.com] > > > > Sent: Tuesday, February 24, 2009 8:53 PM > > > > To: ruby-c...@ruby-lang.org > > > > Subject: [ruby-core:22448] Re: YASNP (Yet Another Selector Namespace > > > > Proposal) > > > > > > On Feb 24, 2009, at 11:29 PM, Jim Deville wrote: > > > > > > > As an example, what if I am using Merb, and two plugins, which all > > > > > define a namespaced method, which I want to change. That's three > > > > > namespaces that I have to __know about__ and modify. As opposed to > > > > > one now. > > > > > > I must admit, I'm a little confused by the above. Maybe we have > > > > different understandings about what selector namespaces are and what > > > > they do. > > > > > > If three plugins each define a method named "xyz" in different > > > > modules, you have three different methods in three modules. Adding > > > > namespaces doesn't change that. All the namespace does is allow > > > > programmers to say "Over this section of code, calling a method named > > > > 'xyz' will come from this module rather than that module." > > > > > > Could some elaborate about their fears of name spaces creating > > > > fences. I don't quite understand what they are getting at. > > > > > > Thanks. > > > > > > -- > > > > -- Jim Weirich > > > > -- jim.weir...@gmail.com > > > > > Clarification of my example: If three namespaces define xyz, and you > want > > > all of the xyz's to act differently, then you need to modify three > > > namespaces with monkeypatching. This way you change their effects > wherever > > > you use them. > > > > > Rebuttal of my example: As pointed out by Charlie here and offlist, the > > > proper way to handle this conflict of namespaces is to create your own > > > namespace that does what you want. > > > > > Overall, the example wasn't my major point, my point was in asking the > same > > > community that is lively about this discussion, and very creative (just > see > > > the Ruby projects in existence), to come up with ways that this can be > > > misused. Throw them out there so we can see if there is a large > downside. I > > > don't know if there is. This example wasn't meant to prove it wrong, > just to > > > give an idea. > > > > > I guess this kind of falls under bikeshedding, but I think that it is > valid > > > to partake in some of this kind of brainstorming before this, or any, > > > proposal is accepted. > > > > > JD > > > > -- > > Yehuda Katz > > Developer | Engine Yard > > (ph) 718.877.1325 > > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 --001636e90729b6d74b0463c26aa6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2009/2/25 Brian Ford &= lt;brixen@gmail.com>
<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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 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, a= nd I'd
> love to have it!
> -- Yehuda
>

Seems Google ate my reply to this.

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?
You put any core extensions that you don't want to automatically expos= e globally into your namespace. Then you use that namespace in your library= .
=A0
The esse= nce of my objection is that you will so cleverly put into a SN
a method that someone else will want to change.

And? I= 'm not sure we're talking about the same thing. In the proposal, na= mespaces are just regular modules. They can be reopened and modified at wil= l, just like normal Ruby.
=A0
Again, t= here 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.

We can just observe t= he *reality*. In *reality* Merb, DataMapper, and Rails were all using the s= ame names to mean subtly different things. I included one such example in t= he OP. The only way to avoid this is a massive coordination effort on the p= art of every library doing core extensions, which has so far proven unreali= stic, even with the relatively small number of popular libraries we have to= day.
=A0
You thin= k, "I'm so smart about programming my app, no one will want to
monkey patch this method."

That really has nothi= ng to do with the proposal. People can happily monkey-patch anything they w= ant.
=A0
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.

Why? How? You look at the software= . There either is or is not a "using" declaration present. If the= re is not, Ruby behaves as it does today. If there is, it adds some additio= nal behavior. How is this significantly different from the (much more ambig= uous) changes that can be made via module inclusion?
=A0
Complexi= ty 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.

What? The proposal lexically scopes the new behavior. It has noth= ing to do with open classes...
=A0
The following applies just as well to engineering software and
designing languages as to building furniture: http://www.johndilworth.com/95.

+1
=A0


Brian

>
>
> On Tue, Feb 24, 2009 at 9:13 PM, Jim Deville <jdevi...@microsoft.com> wrote:
>
> > > -----Original Message-----
> > > From: Jim Weirich [mailto:jim.weir...@gmail.com]
> > > Sent: Tuesday, February 24, 2009 8:53 PM
> > > To: ruby-c...@ruby-lang.org
> > > Subject: [ruby-core:22448] Re: YASNP (Yet Another Selector N= amespace
> > > Proposal)
>
> > > On Feb 24, 2009, at 11:29 PM, Jim Deville wrote:
>
> > > > As an example, what if I am using Merb, and two plugins= , which all
> > > > define a namespaced method, which I want to change. Tha= t's three
> > > > namespaces that I have to __know about__ and modify. As= opposed to
> > > > one now.
>
> > > I must admit, I'm a little confused by the above. =A0May= be we have
> > > different understandings about what selector namespaces are = and what
> > > they do.
>
> > > If three plugins each define a method named "xyz" = in different
> > > modules, you have three different methods in three modules. = =A0Adding
> > > namespaces doesn't change that. =A0All the namespace doe= s is allow
> > > programmers to say "Over this section of code, calling = a method named
> > > 'xyz' will come from this module rather than that mo= dule."
>
> > > Could some elaborate about their fears of name spaces creati= ng
> > > fences. =A0I don't quite understand what they are gettin= g at.
>
> > > Thanks.
>
> > > --
> > > -- Jim Weirich
> > > -- jim.weir..= .@gmail.com
>
> > Clarification of my example: If three namespaces define xyz, and = you want
> > all of the xyz's to act differently, then you need to modify = three
> > namespaces with monkeypatching. This way you change their effects= wherever
> > you use them.
>
> > Rebuttal of my example: As pointed out by Charlie here and offlis= t, the
> > proper way to handle this conflict of namespaces is to create you= r own
> > namespace that does what you want.
>
> > Overall, the example wasn't my major point, my point was in a= sking the same
> > community that is lively about this discussion, and very creative= (just see
> > the Ruby projects in existence), to come up with ways that this c= an be
> > misused. Throw them out there so we can see if there is a large d= ownside. I
> > don't know if there is. This example wasn't meant to prov= e it wrong, just to
> > give an idea.
>
> > I guess this kind of falls under bikeshedding, but I think that i= t is valid
> > to partake in some of this kind of brainstorming before this, or = any,
> > proposal is accepted.
>
> > JD
>
> --
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325




--
Yehuda Katz=
Developer | Engine Yard
(ph) 718.877.1325
--001636e90729b6d74b0463c26aa6--