Peter Vanbroekhoven explained:
> On Wed, 19 Oct 2005 dave.burt / gmail.com wrote:
>
> Did you mean the following? (Otherwise the class definition of Bar is 
> useless.)
>
>    Foo = Bar

Quite. Let's imagine that's what I said.

> There are a few subtle differences:
> * In the second snippet, Foo and Bar are the same. This means that code
>   that changes Foo changes Bar as well. In the first snippet, Bar is
>   invisible to someone using Foo. Changing Foo only changes Foo and leaves
>   Bar alone.
> * In the second snippet, existing instances of class Foo are not affected,
>   while they are in the first case.
>
> So the basic idea is the same, but a cut is designed to keep existing code 
> from breaking. It's supposed to be non-intrusive. That's what a cut does 
> and your second snippet does not.
>
> Actually, in the beginning we considered something like your second code
> snippet, but we decided it was not sufficient for our purposes as we 
> wanted to allow sneaking in a cut into an existing class hierarchy without 
> breaking the code that uses and changes these classes.

OK, great. I'm starting to see the usefulness of this. It occurs to me that 
there is some similarity between this and selector namespaces (targeted for 
Ruby 2) -- a lot of what I imagined namespaces being useful for (i.e. making 
changes to a core class that only affects code within a particular limited 
context) is accomplished easily using cuts.

I still don't know anything, really, about Ruby namespaces. Something else 
to look forward too, and something complementary to this, I guess.

Last thing, a criticism: shouldn't cut be a module, but not a class, because 
classes are instantiable?

Cheers,
Dave