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: Dynamic type system for Ada Date: Wed, 25 Jan 2017 15:55:45 -0600 Organization: JSA Research & Innovation Message-ID: References: NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1485381346 11507 24.196.82.226 (25 Jan 2017 21:55:46 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 25 Jan 2017 21:55:46 +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:33165 Date: 2017-01-25T15:55:45-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:o69n9s$ogk$1@gioia.aioe.org... > On 24/01/2017 22:21, Randy Brukardt wrote: > >> I do wonder how useful such a hierarchy would be, but I suppose someone >> would have to build it to find out. > > Not much. I did exactly this before. > > The problem is that you get the "god-class" in the end. In order to be > able to re-interpret the value as a given scalar type you have to add a > primitive operation to the abstract base. E.g. > > function As_Unsigned_32 (Value : Abstract_Variable) > return Unsigned_32 is abstract; > -- Raises Type_Error if not of the type > > And so for each scalar type. And for arrays and records. I'd probably put such routines higher in the hierarchy (the above would appear under "Root_Numeric", for instance), but you are correct that they are needed (and the reverse as well, to give a way to import values, esp. literals). And I have no idea how to deal with most user-defined types (enumerations, records, tasks, etc.) in such a scheme. (The interface of arrays is simple enough that I can imagine some mechanism to deal with a subset of them.) > Otherwise you have to explicitly convert (upcast) to specific instance > derived from Abstract_Variable which is much worse. That's how all of my hierarchies work. I doubt that I'd call it "much worse"; it avoids "god-classes" and allows most of the checks to be made statically (you can't use operations of the wrong type). It's often easy to apply those upconverts when parameter passing, so they don't end up that wide-spread. But I definitely agree that this is a case where there is always going to be a "bump under the carpet" (as Tucker Taft liked to say during Ada 9x) [you can move the bump to different places under the carpet, but you can't get rid of it (at least without total carpet replacement, which is where this analogy breaks down - but I digress)]. There isn't going to be a totally clean solution. > P.S. I intended to use that on top of a stream exchange, but the interface > is so heavy that it adds no advantage to direct reading the target object > from the stream. I suspect this sort of thing would work pretty well for a hierarchy of numeric types, not so well if other kinds of types are included. There's just not enough overlap of operations for it to make much sense in the general case. Randy.