[ruby-core:22471] Re: YASNP (Yet Another Selector Namespace Proposal)

On Feb 24, 9:17=A0pm, Yehuda Katz <[e-mail]> 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 wo=
uld
> 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?

The essence of my objection is that you will so cleverly put into a SN
a method that someone else will want to change.

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.

You think, "I'm so smart about programming my app, no one will want to
monkey patch this method." 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.

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.

The following applies just as well to engineering software and
designing languages as to building furniture: http://www.johndilworth.com/9=
5.

Brian

>
>
> On Tue, Feb 24, 2009 at 9:13 PM, Jim Deville <[e-mail]> wro=
te:
>
> > > -----Original Message-----
> > > From: Jim Weirich [mailto:[e-mail]]
> > > Sent: Tuesday, February 24, 2009 8:53 PM
> > > To: [e-mail]
> > > 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. =A0Maybe 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 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. =A0I don't quite understand what they are getting at.
>
> > > Thanks.
>
> > > --
> > > -- Jim Weirich
> > > -- [e-mail]
>
> > Clarification of my example: If three namespaces define xyz, and you wa=
nt
> > all of the xyz's to act differently, then you need to modify three
> > namespaces with monkeypatching. This way you change their effects where=
ver
> > 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 downsid=
e. I
> > don't know if there is. This example wasn't meant to prove it wrong, ju=
st to
> > give an idea.
>
> > I guess this kind of falls under bikeshedding, but I think that it is v=
alid
> > 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