>
> Indeed, but it's still a different subject ;-) The point I'm trying to
> address is not _how_ encapsulation should be done, but rather _when_ it
> should be done.


Ah, well my suggestions could be used right now, so long as they're given
suitable names to address their ABI intent. Then just wrap the existing ABI
around that as you gradually transfer responsibility. For example say you
have people relying on class A to have certain parameters, you could rename
it to classes B, C and D for each ABI that is to be shared for class A to
inherit depending on the data model. Then you make class A inherit one of
them based on the data model and treat it forever as an inline. You will
have successfully detached the shared part of the library from class A
without breaking code that compiles with it and modifies it's parameters.
Do likewise for every data model dependent class, struct, integer, etc that
currently exists and you will successfully make it possible to optionally
change the ABI referenced by those now child classes, struct, integers, etc.

On Thu, 11 Jul 2024 at 13:02, Hans <hguijtra_at_[hidden]> wrote:

> On 10/07/2024 16:01, zxuiji wrote:
> > That's a possible method to provide encapsulation, but it does
> nothing
> > to address the existing issue of involuntary ABI ossification. I
> would
> > consider this to be an implementation detail that can be left to
> > whoever
> > is implementing a public interface.
> >
> >
> > It creates a clear divide between the shared ABI and the static ABI.
> > Things like this are possible for example:
>
> Indeed, but it's still a different subject ;-) The point I'm trying to
> address is not _how_ encapsulation should be done, but rather _when_ it
> should be done.
>
>
> Hans Guijt
>
>
>
>