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

On Wed, Feb 25, 2009 at 9:23 AM, Brian Ford <[e-mail]> wrote:
> 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 oppositio=
n is
>> vague FUD... no specific examples of problems that could be caused. It w=
ould
>> be a lot easier to have a lively discussion about specific concerns, and=
 I'd
>> love to have it!
>> -- Yehuda
>>

Your proposal, correct me if I am wrong, is point-of-use not
point-of-definition. In other words, I need to specifically declare
that I am in a namespace so that my method calls will find your
version of the method.

I installed Merb the other day. All *42* gems of it. Let's use that as
a hypothetical example.

Assume that you have a few custom methods spread across Array, Hash,
String, Symbol and maybe Date or Regexp. That is pretty reasonable,
isn't it? You want to use your methods so you need the namespace
declaration in your file(s). But which files? Only the files in which
you use your methods? Then what happens when someone later is doing
some maintenance and forgets to add the using declaration. All the
files? That is a lot of ceremony.

I cannot even comprehend yet what nested selector namespaces would
actually mean/do/look like, but there has to be some way in the
example above to say that your namespace for String, Array, etc are
all active at the same time. The proposed block-ish-not-really syntax
doesn't scale(tm). It would have to be something like this syntax:

using Merb::String
using Merb::Array
using Merb::Hash

Further, suppose that, as Merb does, you rely on a large number of
other libraries. Library X uses a monkey patched core lib method that
you want to change. You can bite the bullet and monkey patch the core
lib method or monkey patch lib X to use your namespaced version. You
can say this is just the risk of monkey patching but it will be a
crazy quilt of monkey patching, some using namespaces and some not.

I am far more worried about comprehending and maintaining previously
written software than with the particular author who is writing it
initially and puts things in namespaces. Polymorphism with inheritance
can already be pretty complex. Selector namespaces, with as yet
undefined super behavior, are a dizzyingly more complex structure to
deal with a fairly mundane software engineering problem that can be
adequately addressed with

1. better design/architecture
2. better testing
3. better/more useful/more complete third-party libraries
4. careful further development of the Ruby core libs APIs

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.

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

>
> 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=
/95.
>
> Brian
>
>>
>>
>> On Tue, Feb 24, 2009 at 9:13 PM, Jim Deville <[e-mail]> wr=
ote:
>>
>> > > -----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. =A0Addin=
g
>> > > namespaces doesn't change that. =A0All the namespace does is allow
>> > > programmers to say "Over this section of code, calling a method name=
d
>> > > '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 w=
ant
>> > all of the xyz's to act differently, then you need to modify three
>> > namespaces with monkeypatching. This way you change their effects wher=
ever
>> > you use them.
>>
>> > Rebuttal of my example: As pointed out by Charlie here and offlist, th=
e
>> > 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 (jus=
t 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 downsi=
de. I
>> > don't know if there is. This example wasn't meant to prove it wrong, j=
ust 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
>
>