Re: How to stop inheritance in a good way?

[Optikos <ZUERCHER_Andreas@outlook.com>]

On Friday, January 17, 2020 at 3:48:02 AM UTC-6, reinert wrote:
> Seems like I end up in a mess if I try to avoid such inheritance :-)
> 
> Maybe better to try to stick properly with the OOP dogmas and shape up the concepts.

Perhaps you should describe •why• you want to elide function B from object2_2_t so decisively & firmly.  Most commenters on this posting are perplexed by why you would want polymorphism via object1_t'Class that is permitted to invoke B in the object2_1_t situation but is prohibited at compile-time* from invoking B in the object2_2_t situation, such as a heterogenous mixture of instances of object2_1_t and of object2_2_t.  You should describe the intended usage in package bodies more (and let the package specifications be rather unrestricted degree[s] of freedom to match your intended usage).  Indeed, doing so might lead you yourself to the solution as you refine your thinking; we'd be interested in seeing your solution to your rejiggered problem-statement even if you solve it yourself.

* which seems to be reinert's stated desire, not throwing an exception at run-time

Because we cannot completely see the intended usage in the package bodies and what precisely needs to be prohibited at compile-time and where, we cannot really present a detailed solution, nor discuss intermediate to advanced topics such as invariance, covariance, contravariance, and bivariance (not all of which are supported by Ada directly or by emulation).

Conversely, I have seen such defeat-the-isa-contract questions arise perennially in multiple OO programming languages for decades, so this is in the ballpark of some question that deserves a no-no don't do that do this instead style of answer.  Usually the answer to a similar question touches on 1 or more of:  covariance, contravariance, declaration-site variance annotations, and/or usage-site variance annotations (or in the case of C++, dangerous techniques and/or various forms of type casting and/or slicing aberrant behavior).

One solution could be that invoking object2_2_t's B is not a compile-time error (and not a raised exception either) but rather simply a do-nothing no-op in the object2_2_t case when invoked polymorphically via object1_t'Class.  This would be an application of the no-harm-no-foul principle.  But we cannot see whether this elision at run-time fits with reinert's intended usage throughout package bodies.