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!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: class wide iterable (and indexable) Date: Mon, 7 Jan 2019 15:07:10 -0600 Organization: JSA Research & Innovation Message-ID: References: <2a6929c5-72fa-4d84-953a-44ea4597ab38@googlegroups.com> Injection-Date: Mon, 7 Jan 2019 21:07:11 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="32059"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-RFC2646: Format=Flowed; Response Xref: reader01.eternal-september.org comp.lang.ada:55240 Date: 2019-01-07T15:07:10-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:q0pvlp$1vp1$1@gioia.aioe.org... > On 2019-01-05 10:21, Randy Brukardt wrote: >> "Dmitry A. Kazakov" wrote in message >> news:q0n6av$1tqs$1@gioia.aioe.org... >> ... >>> In real programs dispatch is rare, thus there is no overhead. >> >> This is probably true, but then interfaces are even more useless (they >> provide nothing that could possibly be of value other than dispatch!). > > From the SW design POV they provide a description of an interface, which > is a lot of value as is. That's primarily the job of package specifications, how the contents are structured isn't very relevant from a description standpoint. ... >> ... >>> No, interfaces cannot contain common code except for class-wide one. Is >>> that what Randy meant about overhead? >> >> Not really. My main point is that you'll never have more than one >> concrete >> instance of a generic interface in any individual program (certainly not >> of >> an interface like that of a container), > > I don't understand this. Usually I have dozens of instantiations of the > same generics with different actual parameters. Right, but all of those are *different* interfaces because they have *different* generic parameters. You can't mix those types in any useful way, because you almost always have the generic parameter type(s) involved. For instance, for the containers, an interface would have to contain the element type. But that substantially limits reuse, because almost every container instance would have a different element type. You can't even pass just the interface into a generic because you wouldn't be able to call the primitives without knowing the element type. To make such a reuse possible you'd have to pass so many parameters that you are typing instantiations for days. And then the compilation time also would be days. You'd have to be slightly mad to even try it. :-) >> Note: I mean one concrete type, there might be many objects of that type. >> But it doesn't make sense to use bounded and indefinite containers at the >> same time for the same element type. > > Of course it does. The best example is Ada strings, a container of > characters. Practically every program in effect uses both bounded and > unbounded strings, the later, maybe, in the form of access String (I tend > to avoid Unbounded_String). As with many things OOP, there seems to be exactly one example where it works. And everything else it doesn't work (or at least help - it "works" in the sense that you can write it that way and get it to work -- but you've gained nothing, you've just changed the problems). >> Dmitry is of course an all-interface all the time sort of guy. All I see >> from that is a vast amount of typing to get nothing in particular in >> return. > > You get type safety. Otherwise you can always go back K&R C! (:-)) Ada has plenty of type safety without using OOP. >> [But I'm not much of a fan of OOP, either; the big advantage of OOP is >> requiring few recompiles when adding features. That was a big deal in >> 1990, >> but it hardly matters today. (I can recompile the entirety of Janus/Ada - >> 250,000 lines - in 15 minutes or so. Why try to save compiles?) And for >> that, you get to type dozens and dozens of declarations to do anything. > > That is because compilers are no longer large software, not even > medium-size (:-)). My current project takes a half of week to recompile > from scratch [*]. Because you greatly overuse generics in the hopes of making interfaces useful. [You admitted as much at the bottom of this message.] You understand the cost of using interfaces very well, yet don't seem to make the obvious connection. ;-) > And recompilation is not the biggest problem. Deployment of the modules > is. Keeping protocols consistent is definitely a hard problem. (One I'm glad to skip.) I don't see any reason that OOP would help there, though. My attempt at that in the Claw Builder was mostly unsuccessful. >> While the supposedly terrible case statement solution gives you case >> completeness checks, variant checks, and essentially has no more chance >> of >> failure (and costs a lot less, and keeps all of the similar code together >> rather that scattering it about to every different kind of object). > > The main problem is that the "similar" code logically has nothing in > common, except the shared interface. It must be written by different > teams, at different locations and time. Independently tested, used, > deployed, versioned, maintained. The case-statement solution crushes not > only the architecture but all software process. Understood, but I'm a "smaller is better" guy. If the team for the project doesn't fit in a room, you are guaranteed to have to mess. You can only get by then with very strong specifications -- but interfaces themselves don't buy anything there (the reverse, in fact, since they're hard to serialize). The specifications have to include not just declarations and semantics but data layout and protocols and all of that mess that never really works. And you talk about this a lot, so I don't know what it is that you think you gain with interfaces that you wouldn't have with a normal record type and primitive operations. > ---------------------- > * GNAT is awfully slow when compiling specifically generic instantiations, > and I have lots of them. The more I have, the more I hate them. This is the point where I'd usually suggest trying a different compiler. :-) A compiler using shared generics could take a lot less time to compile instances because there is little code involved. OTOH, I don't want you to try Janus/Ada (even on the code that don't use actual interfaces), 'cause the way you use generics would inevitably break stuff and I'd hate to have to debug code like that. :-) :-) Randy.