From: Brian Ford <brixen@...>
Date: 2009-02-25T10:05:50+09:00
Subject: [ruby-core:22441] Re: YASNP (Yet Another Selector Namespace Proposal)

On Feb 24, 3:17�pm, Yehuda Katz <wyc...@gmail.com> wrote:
> 2009/2/24 Eero Saynatkari <ruby...@kittensoft.org>
>
> > Excerpts from brixen's message of Wed Feb 25 00:04:34 +0200 2009:
> > > In implementing Rubinius, we have only encountered one major issue
> > > with redefining a core library method: mathn changing Fixnum#/.
>
> > In addition to overriding, selectors can be used for adding (and,
> > if implemented file-/block-wise, deleting.)
>
> Frankly, the proposal is completely unrelated to something you would have
> encountered while implementing Rubinius. By definition, the core classes are
> globally available, and not suitable for selector namespacing.
>
> > > At least as important (if not more) as seeing what a language feature
> > > makes easy is seeing what a language feature makes hard. What will it
> > > look like in code when folks inevitable try to work around the fences
> > > you erect with your selector namespaces? They will try to work around
> > > them.
>
> The proposal really does not erect any kind of fences. It establishes some
> core extensions for use only inside of a specific file. Nothing stops users
> from reopening the namespaces (in the proposal, they are simple modules) and
> modifying the methods. Likewise, nothing stops users from using the
> namespaces in their own code. There is nothing in the proposal designed to
> block users from doing what they want.
>
> > > Engineering software by trying to protect against the invisible,
> > > unknowable, purely speculative demons that lurk in some future world
> > > leads to horrible languages and even worse software. One of the things
> > > Ruby has going for it is some very good software that judiciously
> > > changes assumptions made at the time other software/code was written.
>
> The proposal is based on real-life problems faced by real-life users using
> real-life frameworks. I captured the use-case in the OP (Rails and Merb both
> defining String#camel_case), which has actually bitten real users trying to
> use Merb with ActiveRecord.

You have misunderstood my point. I'm not saying you don't have a
problem. I'm saying selector namespaces will be used in the way I
indicated. And it will lead to ugly, more confusing software. You can
solve your problem without selector namespaces. Instead of focusing on
why you think they are a good idea, I suggest considering how they can
be misused.

All you are saying is you want a way to define methods on the same
class with the same name but different behaviors, where the particular
method called is selected by context. I get it. I think it's a bad
idea.

Brian

>
>
>
> > I think the two paragraphs contrast a bit :)
>
> > However, to offer an alternative consideration, how about a real
> > mechanism for "unrequiring" and/or "unextending"? Particularly the
> > non-methodwise variants of selector namespaces could very well be
> > replaced by being able to (really) activate and deactivate files
> > or modules at runtime.
>
> unrequiring is actually more complex of a feature to implement with no
> additional benefits that I can see. unextending doesn't solve the problem at
> all (except to provide a slow and extremely awkward way to emulate the
> feature on an object-by-object basis).
>
> The proposal is actually fairly straight-forward, relatively simple to
> implement, and does not introduce any "barriers" for users at all.
>
> --
>
> > Magic is insufficiently advanced technology.
>
> --
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325