On Tue, Aug 26, 2008 at 6:12 PM, Alex Rousskov <[EMAIL PROTECTED]> 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
