question.md

Leaving aside what is correct and what is not, I have problems putting these two sentences from the chat together (from a purelly technical low-level POV).

1. We can do any change in the WhateverImpl classes without affecting ABI compatibility "because users of library does not use Impl".

2. A change in the public Bcache breaks ABI compatibility "for all programs linked to libstorage-ng, no matter if bcache stuff is used at all".

Why changing the Bcache class has an binary influence in the other public classes but changing WhateverImpl does not? How are they different in that regard? As I understand, the fact that WhateverImpl is non-public is a convention, not something the compiler knows.

(2) is oversimplifying things a lot.

It is safe to extend the Bcache class.

It is not safe to modify its behavior, the semantics of any parameters to its methods (including the constructors!), or to remove any method.

That's basically what Arvin wrote in IRC this noon:

[12:35:03] <jilopez> arvin: question. If we do not remove the method Bcache#has_bcache_cset,  is the ABI preserved?
[12:41:14] <arvin> jilopez: that was just one example. no function may be removed, nor renamed, nor take different parameters, nor return a different type
[12:42:08] <jilopez> umm, so even adding a type we need to break the ABI, because #create should receive the type, isn't it?
[12:42:18] <arvin> jilopez: many more things are not allowed, e.g. rename classes, change size of class objects, change class hierarcy
[12:42:39] <arvin> jilopez: you can overloaded it
[12:43:37] <jilopez> arvin: can method definition change?
[12:43:46] <jilopez> arvin: implementation I mean
[12:44:46] <arvin> yes, implementations can change - just the behaviour should not change (but it of course even does for bug fixes)
[12:45:11] <arvin> when adding functions in the API the minor library version must be increased

...

[12:53:22] <jilopez> ancorgs: what do you think? Would it worth to preserver the ABI by adding #has_bcache_cset and #has_bcache_cset to Bcache base class?
[12:53:47] <jilopez> sorry, #has_bcache_cset and #attach_bcache_cset
[12:55:32] <arvin> that also will not keep the ABI AFAIR. changing Bcache from being concrete to abstract should not be allowed.
[12:58:26] <jilopez> arvin: so, if a class becomes a base class, and no real instances of that base class are created, ABI is not kept?
[13:01:34] <arvin> well, I assume that changing a class from concrete to abstract breaks ABI. and Bcache should be abstract if only BackedBcache and FlashBcache can exist.

(2) is oversimplifying things a lot.

It is safe to extend the Bcache class.

It is not safe to modify its behavior, the semantics of any parameters to its methods (including the constructors!), or to remove any method.

Sure. In both cases (1 and 2) I meant doing intrusive changes like changing parameters or removing methods.

My statement is a bit out of context: Changing the major library version (a consequence of the ABI break) breaks linking for all programs (unless both the old and the new library are provided (and thus also both maintained)).

Ok. Got it. Thanks.