$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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