On 12/11/07, Curt Sampson <cjs / cynic.net> wrote:
> On 2007-12-11 17:22 +0900 (Tue), Robert Klemme wrote:
> > 2007/12/11, Tim Hunter <TimHunter / nc.rr.com>:
> >
> > > For a problem of this scale, it seems like it would make sense to use a
> > > custom class that had some of the methods of String - enough for the
> > > callees to treat it like a String - but not in fact String. Give it a
> > > .to_s method to convert to a real String when it's really necessary.
> >
>
> I should perhaps explain that the common case is that the strings
> are examined, but not modified. Particularly common is a relational
> restriction: abort processing that row (for that particular chain of
> Conditions and Results) if a data item doesn't match a particular value,
> or fall in between some particular values, or whatever. Actually needing
> to copy a value is relatively rare. More frequent would be incrementing
> a counter if a value matches some condition, or adding the value to a
> total.
>
> I should also explain that having these pseudo-strings as actual Ruby
> objects immediately after parsing is partly a convenience; in something
> that needed to be really fast, the initial Conditions, at least, and
> later ones and Results, if they match frequently enough, would be in C,
> and I suppose I could delay creating the String objects until I had to
> call a Ruby routine.
>
Would the immutable Rope implementation from RubyQuiz 137 help here?