Re: pseudo-specs for a String class

On Tue, Aug 26, 2008 at 6:12 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> Kinkie,
>
> Thanks for the details. I agree with most of your design choices so
> far. I think you are on the "simple refcounting" side of the
> BetterStringBuffer debate so I will let Amos argue for a "internal
> buffer knows its users" design as a starting point.

I'll try to articulate my opinion a bit further. It's as simple as
"implementation doesn't matter right now". Well, almost.
The biggest issue we have now is in the _callers_. They do too much,
they are complex, hard to read, maintain and improve.
And they have to cover a lot of corner cases: "but what if this buffer
which should have been initialized upon instantiation has disappeared
in the meanwhile? Let's throw an assert so that if the distributed
state of this module is broken we know"
This makes the callers bloated, with lots of low-intelligence code
duplication which we can really do without (the code and the
stupidity; I'd prefer us to invest our brainpower in intelligent
things).

So I've decided to attack this kind of problems: bring the transition
to c++ forward, and try to work on the interfaces and the callers.
Once we have properly abstracted them, we have plenty of time to make
them as smart as we want. We must however try to avoid one typical
pitfall of high(er)-level languages: overdesign.

Now, what are the next steps for this particular effort: given the
targets and constraints, a naive implementation like the one I
detailed in the Wiki and embodied so far in code is actually simpler
than I thought it'd be, and I'm quite encouraged - I'll admit I wasn't
(and still am not) sure where it'll end.

Thoughts? Rotten tomatoes?

-- 
 /kinkie