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: Extending a third party tagged type while adding finalization Date: Mon, 11 Dec 2017 16:42:00 -0600 Organization: JSA Research & Innovation Message-ID: References: <4db43571-7f86-4e73-8849-c41160927703@googlegroups.com> <6496a10f-c97e-4e42-b295-2478ad464b2f@googlegroups.com> <6106dfe6-c614-4fc1-aace-74bf8d7435e3@googlegroups.com> <24767ee5-cda8-45e4-98d1-7da44757bd40@googlegroups.com> <037e7f02-9149-4648-b7c5-91f67c1c1961@googlegroups.com> Injection-Date: Mon, 11 Dec 2017 22:42:01 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="29060"; 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: reader02.eternal-september.org comp.lang.ada:49450 Date: 2017-12-11T16:42:00-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:p0lhk4$1okm$1@gioia.aioe.org... > On 2017-12-09 01:17, Randy Brukardt wrote: I was going to write a longer response, but I think we understand each other's positions and we're unlikely to change each other's mind by further talk. (And no one else seems to be reading this...) So just a closing summary. ... >> But most mixed operations don't clearly belong to one ADT or another. >> They're just things that need to be done. (Indeed, the entire top-level >> of a >> program tends to be in this category - it's not going to be reusable >> since >> it is tied to a particular task, it's not going to be commonly used since >> it >> is the high-level operations for a particular task - and as such, >> spending >> much time at all figuring out what abstract entities are involved is >> wasted. >> Just get the job done, spend the effort on the building block parts of >> the >> system that will be reused.) > > See, you mow all type abstraction running all the rest basically > weakly-/untyped. Why bother with ADTs if you don't let them grow? Changing ADTs can be very difficult. (That's especially true for full OOP designs.) And it is highly unlikely that one will get the initial design correct. So in the interest of getting the maximum work done for the minimum effort, it's necessary to draw a line at a point where the advantages of ADTs are outweighed by their disadvantages. And they have clear disadvantages for code that isn't well-understood or experimental or is a pure one-off. (That's probably 80% of the code I write.) > ... >>>> Based on this definition, almost nothing should be an ADT, because very >>>> little can be described only by its semantics. Humm, that's actually a >>>> true >>>> statement; probably we are feeling different parts of the elephant and >>>> describing it very differently. >>> >>> Probably. Things you cannot associate with the semantics are >>> implementation aspects. They can be any so long the semantics >>> maintained. >> >> I suspect you are trying to describe much more of a system by its >> semantics >> than I do. As I previously noted, it just isn't worth the effort to >> figure >> about abstract meanings for things unless they are either very common in >> a >> system or likely candidates for reuse. There's a lot of stuff that has to >> be >> done in programs that defies logical explanation, but that's >> irrelevant -- >> one just has to implement something that passes the test, no one cares if >> it >> is elegant. (It took me a long time to come to grips with this truth.) So >> it's important to realize that one is a lot more productive if one picks >> their spots where to be elegant (where to use an ADT, in this >> discussion). > > Yes, this is our core disagreement. I want everything designed in ADTs > with a stated purpose. I don't think that is practical -- certainly not by me. I don't think abstractly enough to be able to come up with abstract definitions for a lot of things easily. It takes a lot of effort (and time and money), and that effort isn't well-spent for things that aren't ever going to be reused, that aren't a large part of a program, and often are rather illogical (for instance, some of the rules of a real language like Ada). One has to be careful to err on the side of over-designing rather than under-designing, but trying to abstract everything would double the amount of effort it takes (for me, YMMV) to get it built. And re-factoring is always an option if it turns out that an ADT would actually have been useful. Randy.