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!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Smart Pointers and Tagged Type Hierarchies Date: Mon, 31 Jul 2017 23:07:49 -0500 Organization: JSA Research & Innovation Message-ID: References: <2017072417413775878-contact@flyx.org> <2017072721383428219-contact@flyx.org> Injection-Date: Tue, 1 Aug 2017 04:07:50 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="30130"; mail-complaints-to="news@jacob-sparre.dk" 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.7246 Xref: news.eternal-september.org comp.lang.ada:47537 Date: 2017-07-31T23:07:49-05:00 List-Id: "Felix Krause" wrote in message news:2017072721383428219-contact@flyx.org... > On 2017-07-24 21:24:58 +0000, Chris Moore said: > >>> * A derived type, if it wants to provide additional operations (like >>> Current_Position), must not only derive from Instance, but also from >>> Reference, to be able to provide an type-safe interface to those >>> operations. >> >> Why? All ops on Instance-derived types (including constructing >> subprograms) should be in terms of that type. References are for access >> only (ho ho). > > Well, if the smart pointer for File_Stream is the same type as the smart > pointer for Stream, I'd need to downcast the retrieved access type each > time I want to call a subroutine only defined for File_Stream, such as > Current_Position in my example. An explicit downcast is undesirable > because it implies that it may fail, which it cannot when I create a > File_Stream reference with a construction subroutine and subsequently call > Current_Position on it. Our experience with Claw eventually led to an in-house rule that all access types (and pseudo-access-types like smart pointers would be the same) had to be access-to-classwide. Once we did that, we found that we could avoid most explicit type conversions by using dispatching; we did need a few in cases of operations only defined for a subset of child types. There are no "casts" in Ada. Moreover, talking about "up" or "down" when talking about type conversions is confusing, mainly because many computer people apparently have never seen an actual tree. I can speak from experience when I say that I've seen thousands of trees and almost every one of them had the roots on the bottom. (The rest were windfalls and had the roots on the side...:-) Ergo, "down" in a tree is inherently toward the roots. Since a lot of people like to draw their trees upside down, they're confused about where the root of a tree is. The only solution to that is to be explicit: convert toward the root or toward the leaves. The only thing a "downcast" should be used for is fly fishing (and I *hate* fishing :-). If you want people to understand, "cast" out that terminology. Randy.