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

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

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.


--
Magic is insufficiently advanced technology.