Eero Saynatkari wrote:
> 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 and unextending make global changes. I think the selector 
namespace ideas being bandied about are a nice way to hook calls within 
a given context without invading core classes or making global changes 
that could break other people's code. In truth, I think good selector 
namespace could actually reduce the need for and danger of 
monkeypatching, since you can make safe localized changes.

If I were to mock up a proposal, which one should I go with first? 
Someone propose me a spec.

- Charlie