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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? Date: Wed, 29 Aug 2018 10:20:43 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <309225242.556906218.575482.laguest-archeia.com@nntp.aioe.org> <2145221813.556924687.162377.laguest-archeia.com@nntp.aioe.org> <3892c779-2924-405c-b88d-19389fc5ba3e@googlegroups.com> <1ceec6d8-c5c4-49b1-9808-a3580bba3f8e@googlegroups.com> NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:54290 Date: 2018-08-29T10:20:43+02:00 List-Id: On 2018-08-29 02:16, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:pm2tfi$1sv1$1@gioia.aioe.org... >> On 2018-08-27 23:27, Randy Brukardt wrote: >>> "Lucretia" 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. >> >> 1. How do you extend Choice: > > Why would you want to? In the case of something like a compiler, there is no > reason to extend anything rather than simply modifying it to add the > additional capabilities. Which makes the initial claim void. There is no nightmare and nothing to override what is not known in advance. For each "when" of the variant case there is an "override" in the inheritance scenario. If you know all "whens" you also know all "overrides". >> Since nothing of that kind is possible, what you propose is monolithic >> design AKA "god-class", when the variant record must know *in advance* all >> future "extensions", which are extensions no more. > > Why in advance? One *modifies* code in maintenance; one doesn't tie both > hands behind your back! It's hard enough to work on a compiler without > making arbitrary rules preventing the modification of types. That is the exact meaning of "in advance": before the final version of the program unit gets ready all variants must be known. >> You will need to change the declarations of Choice and Var each time and >> then revisit all client code they appear. > > Yes, of course. And Ada makes this easy to do safely. Mostly yes, but the distributed overhead of maintenance is still there and it is no so safe as advertised. Consider the client code: if Current.Token = Integer_Token then -- Do something else -- Do something else end if; Here Integer_Token was used in the meaning "scalar". Later on somebody adds Float_Token and boom, it meant to be "scalar"! Even if replaced by case it is still could be unsafe if subtypes used: case Current.Token is when Scalar_Tokens => -- A subtype with Integer_Token in it when others => end case; You must remember to make the subtype Scalar_Tokens covering the newly added Float_Token or else you get an intractable bug. Note that inheritance would handle this safely. It will be: Current.Token.Do_Something; -- A dispatching call override Do_Something would be abstract must-be-overridden for Float_Token. >> And if the above were possible, how would it be different from inheritance >> as we know it? > > Inheritance is nearly useless! It helps a tiny bit in code reuse, but it is > better still to only write the code once! Having to write dozens of > overridding subprograms that don't actually add any semantics is just busy > work of no value. It helps massively, especially interfaces, of course only when used properly during analysis and design phase in order to describe abstraction. One should use the strengths of typing instead of working around them. Variant records in place of interfaces is a path leading to weak typing. I don't say that one should never use variant records, I say that one should not misuse them. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de