From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2002-09-17 16:34:26
On Tue, 17 Sep 2002 22:37:00 +0300, "Peter Dimov" <pdimov_at_[hidden]>
>From: "Gennaro Prota" <gennaro_prota_at_[hidden]>
>> On Tue, 17 Sep 2002 13:35:02 -0400, Beman Dawes <bdawes_at_[hidden]>
>> >Now someone might say that such a modified interface proposal is no
>> >existing practice. But the LWG takes a wider view, and expects some
>> >changes as an interface is readied for final submission to them.
>> But I think many people use boost also because there's the (not so)
>> implicit idea that they will have less to modify in their code
>> (compared to some home-rolled solution) when the components they need
>> will be standardized. What you describe above means that this
>> advantage is really nonexistent, no?
>It's still true.
>Scenario A: people use library X. Something gets standardized. Modifications
>required if they want to migrate to standard components.
>Scenario B: people use boost::Y. boost::Y gets standardized. Some
>modifications required, but less than scenario A.
Well, this may be true or false. You are just _assuming_ that there
will be less to change. Of course I see that from a practical
perspective there's a problem. Nobody can guarantee that he can bring
his library to the committee's attention and get it approved as is at
the first try :-) Anyhow, I think at least some sort of feedback to
the users would be nice. I mean something that warns them that
specific changes are being considered by the committee and, possibly,
providing an area (on the model of the files section, for instance)
where they can see what is the version under discussion (correct me if
I'm wrong, but I presume that in a situation like that of regex
described by Mr. Dawes, the original author must *write* a new version
anyway, thus letting boost users see it would not be an additional
effort; just an upload...).
>Or for a different perspective: imagine a hypothetical situation where
>boost::Z's interface can be improved.
>Case 1: boost release 1.NN contains a new version of boost::Z that later
>Case 2: boost::Z stays as is, when it gets standardized, std::Z adopts the
>Case 3: boost::Z is standardized as is, and we are stuck with an inferior
>Which one would you prefer?
I'm never in favor of inferior solutions. You are talking to someone
that would be happy to break a lot of perverse code that is legal in
C++ only because it was in C, so no problem for that :-) In fact, I'm
also in favor of modifying already released libraries. Let me make an
example: the new dynamic_cast doesn't support anything along the lines
of bit iterators. OTOH, it uses "block iterators" for many functions
and, in practice, it exposes the idea that the bits are stored into
blocks. An idea which, of course, is not part of the abstraction. Now,
I wouldn't be surprised at all to hear, if that component was proposed
to LWG, that some member objected to such things. In that case it
would be ok for me to "freeze" the current implementation/interface
and start with a new one, so that users that were using the old
version could continue using the freezed version. And others could go
on with the new stuff. At least, in this case the change would be
known to everybody and, those who can "follow" the changes would do it
as soon as possible. That's just an idea, of course, which I only
propose with the intent that it's useful.
>> Also, I haven't understood Mr. Abrahams idea about a boost release
>> being "something available". I think we should not forget that when
>> boost releases there will certainly be a lot of people that will start
>> using the released code. If the goal is only to have the code
>> available for the committee why not creating e.g. a "committee
>> sandbox" instead of binding people with something released in a hurry
>> and, above all, not (expressly) for their use?
>This is out of context. 1.29.0 was supposed to go out a month ago. That's
>the problem that is being discussed.
>I see nothing wrong with the fact that the committee is part of Boost's
>target audience, so to speak. There is no conflict of interest.
Yes, but what's the difference between something being in a release
and something being, say, in the CVS?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk