Boost logo

Boost :

From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-05-31 16:05:24


David Abrahams wrote:
> It did seem to me that when several people have said "this aspect of
> the design seems to complicate things for too little advantage", your
> reaction was to defend it ever more vigorously, declaring yourself to
> have "proven" things that seemed to me far from well-founded, and with
> not very much consideration given to the opposing arguments

Some of the opposing arguments didn't seem to be well-founded either.

> -- in fact
> IIRC you said that *no* technical reasoning against the design choice
> had been given, when I definitely made some technical arguments.

I mainly agree. I guess this was probably one of the main points of
misunderstanding. Most of your arguments were theoretical and I brushed them
aside as not being relevant in practice (sometimes without clearly saying
so). Instead of "technical arguments" I should definitely have said
"arguments backed by real-world use-cases". I apologize for not spelling
this out clearly.

>> BTW, I don't think that it is completely invalid either. What this
>> all really boils down to is an interface that is easy to use and
>> works well for the vast majority of the use-cases and requires
>> workarounds for a minority of the use cases. I insisted on an
>> example also to show how simple those workarounds can be and I doubt
>> that they can typically even be called workarounds as they don't
>> make machine design worse in any way
> ^^^^^^^^^^
>
> This is the kind of argumentation I'm talking about. Having to repeat
> the would-be exit action in all outgoing transitions *is* worse in
> some ways. Duplication of code or logic is evil.

The word "typically" is important. I don't doubt that it *can* make the
design worse in a *few* cases. But anyway, I see that a change on my part is
in order. I will no longer attempt to judge whether something is relevant in
practice or not. I did before because I feared (and still do a bit) that
this could lead to a number of additions that might not be very useful in
practice and would therefore needlessly bloat the interface and complicate
the implementation. As long as a requested feature can be justified
theoretically and the implementation is relatively easy, I will add it.
Reviewers can then later vote whether to keep the feature or not.

Regards,

Andreas


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk