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!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: Full view of a private partial view cannot be a subtype Date: Tue, 5 Dec 2017 14:59:03 -0600 Organization: JSA Research & Innovation Message-ID: References: <889a3aed-4e6b-49c8-8c1c-6f1478e8e077@googlegroups.com> <43498b2a-773c-454a-b0e7-ade5d6594bd4@googlegroups.com> Injection-Date: Tue, 5 Dec 2017 20:59:04 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="2895"; 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; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:49388 Date: 2017-12-05T14:59:03-06:00 List-Id: "Shark8" wrote in message news:43498b2a-773c-454a-b0e7-ade5d6594bd4@googlegroups.com... ... >Besides UIs, the one problem that springs immediately to mind is the >internals of a >compiler's IR/parse-tree. I can speak to this (at least somewhat), and I think the full OOP version would be a nightmare. Janus/Ada (originally designed in the early 1980s, before there was such a thing as type extension) uses variant records controlled by enumeration discriminants. That is a very effective organization in Ada, because of two features of Ada not found in most other languages - case completeness and variant component checks. Case completeness means that adding/removing a variant is relatively easy: most case statements that need changing are called out by the compiler. Time has proven that it isn't even worth looking for change locations since the compiler will point them out much quicker than one can find them. Similarly, adding/removing/moving/modifying components in the variant either cause compiler errors (see above) or runtime errors from accessing non-existent components. With good testing (easy for an Ada compiler - the ACATS provides the needed foundation), the runtime errors will point out the majority of other changes needed. Indeed, I've been introducing additional variants into the Janus/Ada data structures in order to get even more advantage from these features -- they eliminate large amounts of debugging that would otherwise been necessary. I've never tried an OOP compiler tree, but the Claw Builder uses an OOP organization both for the GUI and for the code generation. And that did not really work out well. There is so much boilerplate that has to be constructed for every new widget type (to declare all of the overriding routines, to provide basic implementations for those routines, and the like) that there is a strong dis-incentive to adding new widgets. (The last time I tried to add a widget, it took over 2 days solid coding to get to a compilable type.) And the boilerplate didn't seem (for Ada) to make anything easier to implement or debug. Similarly, adding a new kind of code generation (something that happens frequently with the Builder, probably would happen fairly often for a compiler as well) is a nightmare, as the new dispatching routine has to be added to every existing widget. By abandoning traditional OOP, one could do a bit better (especially by implementing many concrete operations in the root classes -- meaning, in Ada terms, that they can't be interfaces), and maybe some of the boilerplate could be reduced - but to do so, you'd have to introduce even more operations. The number of dispatching operations alone was becoming daunting. Thus, I'm unconvinced that a compiler data structure would be any advantage written in OOP (at least, if the "conventional" version was written in Ada). I suspect the reason that OOP held some much advantage to many programmers (read, C programmers) is that they had a language which provided no help at all for "conventional" programming, while Ada already had information hiding, true privacy, case completeness, variant component checks, array index checks, etc. So the increment is so much less. I think the only place OOP really holds an advantage is for programs based around call-backs (like most GUIs). And I think you'd be nuts to use call-backs if you don't have to, so there isn't much need for OOP (assuming it is compared to "conventional" Ada and some some other language that lets one do anything, no matter how unintended). Randy.