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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: class wide iterable (and indexable) Date: Wed, 9 Jan 2019 18:06:26 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <2a6929c5-72fa-4d84-953a-44ea4597ab38@googlegroups.com> NNTP-Posting-Host: i065DRYuysvTI4qVnaNkyg.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:60.0) Gecko/20100101 Thunderbird/60.4.0 X-Notice: Filtered by postfilter v. 0.8.3 Content-Language: en-US X-Mozilla-News-Host: news://news.aioe.org Xref: reader01.eternal-september.org comp.lang.ada:55250 Date: 2019-01-09T18:06:26+01:00 List-Id: On 2019-01-09 00:26, Randy Brukardt wrote: > But that's the point: there aren't any significant tagged classes here, just > generic classes, because there is only one instance of each class (use of > formal packages can't change that). This is what I do not understand. Instance of a class is a type. Do you mean the depth of the hierarch,y probably? Because the number of sibling instances is usually large. > There's no point in having more (unless > you like adding complication for the sake for doing that). > >>> 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. :-) >> >> I don't see your point. You argue that generic-based design of containers >> is bad. Of course it is bad. > > No, I argue that given that there is no realistic alternative (other than to > abandon strong static typing by deriving everything from a common type, then > store Object'Class). It cannot be Object'Class because that includes limited types etc. There are lots of constraints on the elements depending on the container, like ordering, hashes. These constraints must be spelled in the language, not silently assumed. A named interface is a language to spell such constraints. #1. The instances must be further constrained by the user from his side. Just like we declare an array type, it does not mean that it can hold any elements from the class of definite types. #2. It seems that you mix constraints #1 with #2. > If there was a way to have a universal container interface independent of > the element type (and have that be useful), then the concept would be a lot > more useful. But that isn't possible in any Ada-like language and retain > static typing. I do not understand why. Create an anonymous instance, clone the hierarchy, constrain Element'Class to the concrete type T. Everything must be done by the compiler in one step as it does for array types. > The place where interfaces actually have some use > is where you have an abstraction with a variety of representations and > uses -- such as strings or math. That's rare, though, and pretty much only > happens in the language-defined libraries.) Yes, it depends on the level of reuse. The libraries are massively reused. The point is that in a large project you have such things too. You must have them otherwise you will not be able to manage complexity. > Which makes sense to me, since the primary benefit of inherited types is > implementation reuse. Which interfaces don't allow. I'd surely support this > position, but I think it is impractical to implement (as well as define > properly rules for). Right, this is our main conceptual disagreement. You want to stick to generics though they have proven not working. The only alternative is inheritance (advanced type system). If only one percent of mental efforts were invested into the type system instead, we could have a different and IMO better Ada today. > Love to do those sorts of things. Know anyone with lots of money that they > don't know what to do with? True to Ada as a whole. My heart bleeds when I see how much resources are wasted on Go, D, C# etc. >> I would gladly use Janus/Ada or ObjectAda if I could. I was a happy user >> of the latter long ago. Unfortunately cross-platformity is a requirement >> in these days. > > Understood. As you know, that costs $$$, and there aren't enough of those to > go around. Sure, we need another crazy billionaire who would invest some bits of his unearned wealth into Ada rather than in digging tunnels in seismically active zones... (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de