From: Dave Thomas Date: 2002-01-28T05:48:59+09:00 Subject: Re: Subrange of String subclass => invalid object Mathieu Bouchard 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