From: transfire@...
Date: 2006-06-04T03:38:10+09:00
Subject: Re: Another Look at SELECTOR NAMESPACES


Austin Ziegler wrote:
> On 6/3/06, transfire@gmail.com <transfire@gmail.com> wrote:
> > 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.
>
> Fortunately, the choice isn't yours.

Wwhy do you have to go and do that? Does making a little digg like that
support your argument?

> I think that what you're wanting
> is going *way* too far into unnecessary and hard-to-understand arcana,
> and the opposite of that is not closed classes. Selector namespaces
> are about *explicit* method selection, not implicit method selection,
> IMO.

I just don't see your point when what you say is *unnecessry arcana*
can already be done --indeed is already being done. There just happens
to be odd exceptions, due to the lack of a more managed approach. For
example, not unlike the one I already gave.

--- foolib.rb ---

  class X
    class String
      def self.new ; 0 ; end
    end
  end

--- bar.rb ---

  require 'foolib'

  class X
    def mystring
      String.new( "Extended!" )
    end
  end

  x = X.new
  x.mystring  #=> 0

Just picking up bar.rb off the ground, so to speak, would indeed seem
pretty confusing. Why is String.new not doing what is should? But
obviously you have to know what's up in foolib.rb. So already one is
subject to context-based behavior. With selector namespaces it actually
becomes less confusing because the namespace declaration would make it
clear that you need to be aware of how that namespace is adjusting the
system. And for the same reason it's actually safer too. With no formal
means of handling it presently we are at the potential whims of each
other's good extension habbits, which in effect limits are ability to
share code and conversely, our ability to expoint the potential of
extensions.

T.