Strategy (was: Re: wordlist-refactor branch complete)

On Sat, Sep 20, 2008 at 9:26 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On Sat, 2008-09-20 at 13:31 +0200, Kinkie wrote:
>> On Fri, Sep 19, 2008 at 9:08 PM, Alex Rousskov
>> <rousskov_at_measurement-factory.com> wrote:
>> > On Fri, 2008-08-22 at 10:24 +0200, Kinkie wrote:
>> >
>> >> The wordlist-refactor branch is from my point of view feature-complete.
>> >> It can be found in Launchpad, at
>> >> https://code.launchpad.net/~kinkie/squid/wordlist-refactor.
>> >> I'm not posting a bundle to propose merging into trunk at this time,
>> >> because despite the patch being quite self-contained, some core
>> >> developers have expressed concerns about it potentially introducing
>> >> subtle bugs, and suggested it to be merged after branching 3.1.
>> >>
>> >> Here's the branch summary:
>> >> Purpose of this branch is to migrate wordlist from a C-style interface
>> >> with some c++ coating into a proper c++ object. It does not aim to
>> >> increase the performance of the implementation, but to have cleaner
>> >> semantics for the callers.
>> >> This branch is an interim step on the way to a proper
>> >> template-library-based class. Collateral advantages include unit
>> >> tests, doxygen documentation and naming convention compliance.
>> >>
>> >>
>> >> I appreciate anyone taking a peek at it and posting any comments.
>> >
>> > *B1* Should we just use std::list or another standard container instead?
>> > It seems like a standard container provides everything the new WorldList
>> > wants to provide. Is this a performance optimization?
>>
>> No. This implementation is an intermediate step, migrating to a
>> standard container is the eventual aim.
>> The whole concept should probably also be phased out in favour of a SBufList.
>
> Understood. So we have a few options here:
>
> 0) Do nothing now. Continue to use C-ish WordList until better String is
> available. Decide what to do next at that time.
>
> 1) Polish and implement new C++ WorldList class that still uses char*
> words. Convert all user code to use that new class. Later, throw away
> that class, replace with some String-based list.
>
> 2) Use existing std::list<SquidString> or similar (i.e., use a standard
> list and the existing SquidString class). Convert all user code to use
> std::list<SquidString>. When proper String is available, replace
> SquidString with String and, possibly, std::list with StringList.
>
> Out of these options, (1) seems to make least sense. Why spend hours on
> inventing a new class that is going to be replaced with something
> better, especially if that something better already exists?

The strategy behind the approach I've taken is: first fix the callers
by making a reasonably OO callee, upsetting the callees as little as
possible. Then make the callee better.
We have plenty of places where the C heritage shows up, and aiming for
the perfect solution is a more difficult task than doing fixing things
in steps.
In this case, I did not invent a new class, but simply ported the
existing interface to C++.

I'd like to understand a bit better what's the forward strategy the
project wants to take tho, as it seems that my development strategy
does not seem to fit well with the overall project's.
What I'm doing is, take a wart and improve it a bit. Maybe not in the
best possible way, but hopefully improve it some. Yet I always seem to
be missing something. In some cases I agree it's something which has
to be fixed before merging can be considered (see the refcounting in
SBuf), sometimes it's just a not-perfect piece of code, but which
still is an improvement over the wart.

Noone else is tackling the issues that I'm working on. Should they be
left alone? Or should I aim for the "perfect" solution each time? But
what is "perfect"? I'm learning as I go - that's one of the reasons
why I make very public RFCs..

So please, tell me what you consider the best way I can help - I'm
obviously not doing well enough.

Thanks,

-- 
 /kinkie