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.