From: transfire@...
Date: 2006-06-04T00:42:08+09:00
Subject: Re: Another Look at SELECTOR NAMESPACES


Austin Ziegler wrote:
> ...all of which sounds *way* too magic to me. The more I look at
> selector namespaces, the less that I like them because they're way too
> magic. Sort of like the decision made in C++ to allow overloading of
> compound assignment operators (+=, -=, etc.) so that c = c + b could
> mean something entirely different than c += b.
>
> I would feel very uncomfortable if basic language structures changed
> on me randomly.
>
> Inasmuch as selector namespaces are limited to allowing multiple
> methods with the same name but different "namespaces", I'll support
> them even though I can't really see much value in them. Beyond that
> ... and I think we're looking at something that is far more confusing
> and abusable than any possible value it could provide.

Well, I would tend to agree with you if were almost any other language.
But given's Ruby dynamics, namely the ability to extend previsously
defined classes and modules, really put Ruby in a differnt ballgame.
Selector namespaces provide a way to manage that. I understand the
downside of  having definitions change based on context, but that's the
trade-off for the flexibility. I really believe Ruby should move foward
with this. But if it's decided that this flexibility is not "good",
then I think Ruby should just close shop on her classes and module
--once defined always defined. I do a lot of meta-coding and I find in
this area Ruby can still be rather frustrating to use b/c it really
hasn't fully embraced itself as a meta-lanaguage.

T.