Re: [boost] Boost Development Environment proposal

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-06-06 11:03:41

David Abrahams wrote:
> on Wed Jun 06 2007, "Martin Bonner" <Martin.Bonner-AT-pi-shurlok.com>
> wrote:
>
>> David Abrahams wrote:
>>> "Emil Dotchevski" <emildotchevski-AT-hotmail.com> wrote:
>>
>>>> The more extensive the refactoring you're doing is, the more
>>>> important it is for you to update often, so you don't deviate from
>>>> everyone else's work too much.
>>>
>>> If that's true, it implies we have libraries with coupled
>>> implementation details [, that] should never happen IMO
>>
>> Hmm.  It's quite easy to depend by accident on implementation
>> details. My favourite example is a component that doesn't document
>> that it returns things in a particular order.  However in version 1,
>> for ease of implementation, it stores things in a std::map - and
>> thus actually returns them in ascending order; in version 2 it
>> upgrades to an unordered_map - and returns things in an arbitrary
>> order.  The result is that a dependant component breaks.  The fault
>> is in the dependant component (it relied on undocumentend
>> behaviour), but finding that before the change can only be done by
>> the most intensive code review (and extensive documentation).
>>
>> Having said all that, I agree that libraries with coupled
>> implementation details should be avoided - but we need to cope with
>> accidental coupling.
>
> Probably.  I only said "should," not "does" never happen.  In any
> case, it will be rare, and in the context of the discussion, if your
> library depends on my implementation details, it deserves to break
> when I update my library.

Hypothetically speaking - I'm not saying that this will be a problem in 
practice - you can't break your dependencies (on the -stable branch) even 
when they deserve it, since the automatic merge script will reject your 
change as causing regressions.