Mathieu Bouchard <matju / sympatico.ca> writes:

> > So, I'm thinking that perhaps something to think about in Rite is
> > having built-in frozen classes for primitive types, _String, and so
> > on. These classes would be no more that value containers: they'd have
> > almost no operators. The implementations of String could then be
> > expressed in terms of operations on these _Strings (probably by
> > delegating to them, rather than subclassing them).
> 
> You don't need delegation here. I'm thinking of two solutions:

No you don't. It would just be clearer.

> 
> 	class SimpleString
> 	  # implemented in C
> 	end
> 	class String < SimpleString; include HollowString; end

This would clearly be bad: String and SimpleString have different
protocols and semantics.

> 	class String; include HollowString
> 	  # equivalent of SimpleString in C goes here
> 	end

I have to admit I've yet to invest time understanding all this
Hollow... business. The underlying issue seems to be a lot simpler
than all this:

1. Classes with complex interfaces should implement those interfaces
   in terms of a small set of fundamental operations. This means you
   can change the overall class by changing the implementation of just
   these operations.

2. Built-in classes such as String should be writable in Ruby. This
   means they need internal helper objects for native storage, such as
   the _String I suggested. These are not min-String objects: they are
   simply containers, accessed only by the fundamental methods in (1).

> This is all very inspiring, but...
> 
> Are we in january 2002, or january 2001 ?

Have the needs changed? And are we any further along?

> anyway, if "we" are going to start somewhere, "we" are better
> rewriting the Regexp class and fixing Ruby's scoping of $1,etc.,
> instead of redoing what's been already done.

The joy of the community is we can each contribute in our own way (as
you have shown).


Dave