[RFC] Workingstyle of different VCS systems

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 12.04.07 16:43:29, Matthew Woehlke wrote:
>> Andreas Pakulat wrote:
>>> On 12.04.07 14:31:49, Matthew Woehlke wrote:
>>>> Andras Mantia wrote:
>>>>> On Thursday 05 April 2007, Andreas Pakulat wrote:
>>>> I just realized a potential issue; do we have a plan for how to go about 
>>>> splitting an interface without breaking the API/ABI if that should be 
>>>> needed? E.g. if we have an interface that provides foo and bar, and 
>>>> later want to implement a back-end for a VCS that only provides bar, 
>>>> what happens?
>>> Well, without much thinking I'd say: create 2 new interfaces. This of
>>> course won't work for the main interface, but all optional should work.
>> Well, yes. The question is can you do something like go back and change 
>> the interface that provides both to being a class which implements both 
>> the new interfaces? Otherwise now you have two problems. First, you have 
>> three interfaces where A+B provides the same features as C. Second, you 
>> have to update everything that provides C to provide A+B.
> 
> Uhm, we don't have to do anything (well we'd probably update svn+cvs),
> the plugin developers would do this. I talked a bit with adymo about
> interface versioning on IRC (yes I know bad place, no history). The
> outcome is basically that in this case it would work like this:
> 
> IFoo is the original interface from which we split out foo (bar stays in
> it). Thus we create IBar with foo() and we also create IFooV2 which only
> has bar(). Now a plugin has a couple of choices:
> [snip other options]
> e) implement IFoo+IFooV2+IBar, thus make sure it is found when any code
> needs any of the 3 interfaces. 

That's exactly what I'm afraid of, but unless we can create IBar and 
IFooV2 and arrange for IFoo to become IFoo : IBar, IFooV2 (without 
breaking BC) then we're stuck with this. I guess we'll just hope this 
never comes up. :-)

OTOH if it's an optional interface I don't see a BC issue if we just 
kill off the old interface; anything that wants to use it is then 
considered "broken". (And in this case intentionally breaking SC is 
possibly a good thing.)

>> I'm not sure if there is any way around that, though, other than perhaps 
>> do this preemptively (i.e. except for the basic interface, not make any 
>> interface that provides more than one sort of function).
> 
> I was going to try to find reasonable grouping anyway.

That's almost certainly the way to go; try to only combine things that 
logically can't exist apart (like lock()/unlock()).

I'm just being proactively paranoid here, so overthinking probably won't 
help. Let's just hope for the best. :-)

-- 
Matthew
Current geek index: 62%