From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a37:5c83:: with SMTP id q125mr39833091qkb.446.1579295859408; Fri, 17 Jan 2020 13:17:39 -0800 (PST) X-Received: by 2002:aca:d985:: with SMTP id q127mr4773315oig.132.1579295859226; Fri, 17 Jan 2020 13:17:39 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!peer01.am4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!g89no7340944qtd.0!news-out.google.com!w29ni1563qtc.0!nntp.google.com!g89no7340915qtd.0!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 17 Jan 2020 13:17:38 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=47.185.239.228; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.239.228 References: <755521b8-d0a8-41bd-b547-da1136e3b8e1@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <7b7ecd25-b3e0-44d8-92a9-0373496e212b@googlegroups.com> Subject: Re: How to stop inheritance in a good way? From: Optikos Injection-Date: Fri, 17 Jan 2020 21:17:39 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 3933 X-Received-Body-CRC: 646027145 Xref: reader01.eternal-september.org comp.lang.ada:57863 Date: 2020-01-17T13:17:38-08:00 List-Id: 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 :-) >=20 > Maybe better to try to stick properly with the OOP dogmas and shape up th= e concepts. Perhaps you should describe =E2=80=A2why=E2=80=A2 you want to elide functio= n B from object2_2_t so decisively & firmly. Most commenters on this posti= ng are perplexed by why you would want polymorphism via object1_t'Class tha= t is permitted to invoke B in the object2_1_t situation but is prohibited a= t compile-time* from invoking B in the object2_2_t situation, such as a het= erogenous mixture of instances of object2_1_t and of object2_2_t. You shou= ld describe the intended usage in package bodies more (and let the package = specifications be rather unrestricted degree[s] of freedom to match your in= tended 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 yo= ur rejiggered problem-statement even if you solve it yourself. * which seems to be reinert's stated desire, not throwing an exception at r= un-time Because we cannot completely see the intended usage in the package bodies a= nd what precisely needs to be prohibited at compile-time and where, we cann= ot 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 perenn= ially in multiple OO programming languages for decades, so this is in the b= allpark of some question that deserves a no-no don't do that do this instea= d style of answer. Usually the answer to a similar question touches on 1 o= r more of: covariance, contravariance, declaration-site variance annotatio= ns, and/or usage-site variance annotations (or in the case of C++, dangerou= s techniques and/or various forms of type casting and/or slicing aberrant b= ehavior). One solution could be that invoking object2_2_t's B is not a compile-time e= rror (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 c= annot see whether this elision at run-time fits with reinert's intended usa= ge throughout package bodies.