Re: wordlist-refactor branch complete

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?

Thank you,

Alex.
Received on Sat Sep 20 2008 - 19:26:45 MDT