From: Trans <transfire@...>
Date: 2007-03-16T10:49:44+09:00
Subject: Re: java guilt



On Mar 15, 1:51 am, Jos Backus <j...@catnook.com> wrote:
>     Hi David,
>
> On Thu, Mar 15, 2007 at 11:27:43AM +0900, David A. Black wrote:
>
> [snip]
>
> > As soon as someone figures out a way to make it work, all will be well
> > :-)  Actually the libraries that allow block-scoped core changes have
> > never been widely used, as far as I can tell.
>
> Are you referring to libraries like `scope-in-state'? AfaIac, these don't do
> what I want them to do, which is the ability to restrict changes made to some
> class while executing code in some other class. This is probably expensive as
> hell and non-trivial to implement. But it sure would be great to have as it
> would make Ruby a "safer" language.
>
> Imagine if you could add String#foo to be visible within class Bar only
> without having to subclass String and use it inside of Bar instead of String
> (arguably the cleanest way to make this work otherwise).

I wrote an experimental lib a while back that let you sub in your
class for another within the scope of another module/or class. I think
it's a pretty easy way to work with this concept. Far-sight better
than the clock based approaches, IMO. The central idea is:

  class InBlanket

    # This would have a even nicer DSL.

    String = Class.new(::String) do
      def to_s; "(" + super + ")"
    end

    def tryme
      puts "three pigs"
    end

  end

  InBlanket.new.tryme  #=> "(three pigs)

This could actually be made to work fairly easily *if* literals used
the ::new methods. Unfortunately they don't. So one would have to do
back and use String.new instead of "".  I consider this a design flaw
in Ruby current implementation, though I'm sure there are
justifications for it (probably execution speed related).

In any case, I think the above is about the most elegant approach
possible for selector namespaces. Every other notation I've seen
deters me due to the spaghetti it makes of the code.

T.