Re: Strategy from Alex Rousskov on 2008-09-20 (squid-dev)

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Sat, 20 Sep 2008 20:04:14 -0600

On Sun, 2008-09-21 at 01:05 +0200, Kinkie wrote:
> 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:
> >> >> 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.

IMO, spending a lot of time on slightly improving large volumes of
working code that should be and will be rewritten is a waste. I
understand that it is mostly your time that is being spent here, but
since we all are supposed to review the code and fix bugs, we are all
affected.

> 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++.

Right. What I am asking is why change one bad interface to another bad
interface when a good interface is already available? Will it be a
little more difficult to put that good interface in? Yes. Does that
imply we should spend time migrating from one bad solution to another
poor solution? No. Will the effort to port old code to the good
interface pay off? Probably, because the good interface will stay for a
long time, will accommodate new String, and will help to fix bugs and
write better code.

> 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.

In general, when big/fundamental code pieces are modified, there should
be consensus how to modify them before the development work starts. If
there is no consensus or no quorum for consensus, the developer can
proceed at their own risk.

> 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.

I think your problems with String are different from the current
problems with WordList, but there is some overlap (other than me bugging
you). If I may, I can suggest the following general approach:

* Look for simpler warts with localized impact. We have plenty of them
and your energy would be well spent there. If you have a choice, do not
try to improve something as fundamental and as critical as String.
Localized single-use code should receive a lot less scrutiny than
fundamental classes.

* When assessing the impact of your changes, do not just compare the old
code with the one submitted for review. Consider how your classes stand
on their own and how they _will_ be used. Providing a poor but
easier-to-abuse interface is often a bad idea even if that interface is,
in some aspects, better than the old hard-to-use one.

> 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?

I hope this email answers these questions, but I am sure other opinions
will vary.

> But what is "perfect"?

There is no definition of "perfect", of course, but the acceptance bar
rises with the number of current and expected users of the code...

> I'm learning as I go - that's one of the reasons
> why I make very public RFCs..

We all learn. I am excited to see you making progress, and I hate to
inflict pain, but my options are rather limited once you submit
something for a review.

To overextend this learning metaphor, a good teacher would not have
given you the assignments you have chosen yourself! I am in no position
to teach, but I did provide a few project ideas below, FWIW.

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

You are actually helping plenty, just not with those two unfortunate
projects!

Here are a few personalized ideas, in no particular order:

For some of the above, I have provided patches that need review,
polishing, and/or testing. I am adding those to bugzilla but not all
reports have been updated.

I suspect others may have different personalized lists of projects and
even consider the String project appropriate...

HTH,

Alex.
Received on Sun Sep 21 2008 - 02:04:40 MDT

This archive was generated by hypermail 2.2.0 : Sun Sep 21 2008 - 12:00:06 MDT