On Feb 24, 2:07 ¨Βν¬ Ωυλιθιςο ΝατσυνοτΌν®®®ΐςυβω­μαξη®οςηΎ χςοτεΊ
> Hi,
>
> In message "Re: [ruby-core:22322] Re: YASNP (Yet Another Selector Namespace  ¨Βςοποσαμ©> on Sun, 22 Feb 2009 11:35:41 +0900, Aaron Patterson <aa... / tenderlovemaking.com> writes:
>
> |+1 as well, but I like the block.  ¨Βος νειτ σεεντο βε νοςε γμεαασ
> |to what is going on.
> |
> |  ¨Βσε ΝεςβΊΊΣτςιξη ½Ύ Στςιξη δο
> | bla blah".some_special_merb_only_method
> |  ¨Βξδ
> |
> | bla blah".some_special_merb_only_method # => doh!  ¨Βοεσξ§τ εψισ>
> +1 to have some kind of selector namespace (it's planned for 2.0
> anyway), but -1 for using block (or block-like syntax) to denote
> namespace scope, because
>
> * it's not really a block
> * too small granularity for namespace switching might bring confusion
>
> I'd prefer per file namespace switching.
>
> matz.

In general, I think selector namespaces are a bad idea, even if they
are planned for 2.0. :( Rather than trying to argue persuasively for
my opinion, I'll throw out a couple things to think about.

In implementing Rubinius, we have only encountered one major issue
with redefining a core library method: mathn changing Fixnum#/.

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 would urge everyone to attempt to truly understand what sort of Ruby
software will be created with selector namespaces.

Cheers,
Brian