2009/2/24 Eero Saynatkari <ruby-ml / 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.


>
>
> 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