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" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Studying and Maintaining GNAT,
 Is There Any Interest in a New Group?
Date: Mon, 27 Aug 2018 16:27:50 -0500
Organization: JSA Research & Innovation
Message-ID: <pm1qcm$3bt$1@franka.jacob-sparre.dk>
References: <d0ae2366-32a2-42ff-8750-4802bbcfd251@googlegroups.com>
 <309225242.556906218.575482.laguest-archeia.com@nntp.aioe.org>
 <ec9cbd0c-51d4-4a55-a2b0-b6c6b96bb9fb@googlegroups.com>
 <ly4lfimepc.fsf@pushface.org>
 <b21b2991-a0b0-46ed-ba49-b5cbad1e9a98@googlegroups.com>
 <2145221813.556924687.162377.laguest-archeia.com@nntp.aioe.org>
 <3892c779-2924-405c-b88d-19389fc5ba3e@googlegroups.com>
 <1ceec6d8-c5c4-49b1-9808-a3580bba3f8e@googlegroups.com>
Injection-Date: Mon, 27 Aug 2018 21:27:50 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk;
 posting-host="rrsoftware.com:24.196.82.226";
	logging-data="3453"; 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:54275
Date: 2018-08-27T16:27:50-05:00
List-Id: <comp.lang.ada>

"Lucretia" <laguest9000@googlemail.com> wrote in message 
news:1ceec6d8-c5c4-49b1-9808-a3580bba3f8e@googlegroups.com...
...
>I never said anything about not learning from DIANA, I said don't
>implement it. Reason is simple, it was designed using Ada83, we have
>OO now and OO fits a compiler perfectly and would be a hell of a lot
>nicer than a bunch of variant records/enums.

Fitting OO into a compiler design could very easily turn into a nightmare of 
required overriding routines, making it very painful to add new kinds of 
nodes. I used a design like that in the Claw Builder, and the OO parts 
gummed up the works to the extent that modification is difficult. 
(Especially if you want to develop code using an agile style, which IMHO is 
the only successful way to develop code.)

Variants and enums in Ada are fully checked (either at compile-time or 
runtime), so a lot of the advantages of OO are also available using them. 
(Case completeness checks in particular make it hard to forget to implement 
something.) And they put the emphasis on the operations rather than on the 
objects, which can be an advantage for some sorts of code.

I don't claim to know the right answer here, but I do know that 
variants/enums/cases are very useful design tool *in Ada* (not so much in 
other languages). If one sticks to a strict OO design, you can easily end up 
working a lot harder than necessary and make maintenance harder than 
necessary.

                                                 Randy.