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 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!reality.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Generic private type declaration Date: Tue, 29 Nov 2016 17:48:06 -0600 Organization: JSA Research & Innovation Message-ID: References: <877f7qy6hf.fsf@adaheads.sparre-andersen.dk> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1480463229 2666 24.196.82.226 (29 Nov 2016 23:47:09 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 29 Nov 2016 23:47:09 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:32523 Date: 2016-11-29T17:48:06-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:o1jpiq$13df$1@gioia.aioe.org... > On 28/11/2016 22:32, Randy Brukardt wrote: >> So, yes, Dmitry, the language could strengthen contracts this >> way -- if one didn't care about usability [or compatibility]). > > Rather one should make contracts more complete. If the formal type "X is > private" may or may not allow type cloning by "Y is new X" of the actual > type, that must be a part of the contract. E.g. tagged types should not > match or, better cloning hierarchies tagged types must be allowed. That would be hard to do, though. It would make generics rather hard to make general. One sees that with formal arrays, where it is necessary to make two versions of each generic, one for constrained array types and one for unconstrained array types. I tend to agree with your usual analysis that generics are never going to really work in an O-O environment. If you make the contracts complete, you'll end up with generics that hardly are generic at all (they'd only work in very limited circumstances). And if you make them really loose (as in C++), you can't really write a body that is certain to work, because too much leaks through from the actuals. Ada's approach tries to tread a middle ground, and as such it isn't satisfying to anyone (but it also allows a lot of things that otherwise would have to be banned unconditionally). Of course, when trying to have ones cake and eat it too, its not unusual to get the rules wrong (either too tight or too loose). I doubt that there really is a solution. Randy.