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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:138f:: with SMTP id 137mr906881itz.18.1546604426032; Fri, 04 Jan 2019 04:20:26 -0800 (PST) X-Received: by 2002:a9d:6f9a:: with SMTP id h26mr1048043otq.0.1546604425854; Fri, 04 Jan 2019 04:20:25 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.166.216.MISMATCH!q69no49263itb.0!news-out.google.com!v141ni67ita.0!nntp.google.com!k10no49228itk.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 4 Jan 2019 04:20:25 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=85.168.19.89; posting-account=O_NgcgoAAABs6pgCjroQBmOBL5ZZGPUc NNTP-Posting-Host: 85.168.19.89 References: <2a6929c5-72fa-4d84-953a-44ea4597ab38@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <9e6b4219-d6ba-4c89-814d-5ea6e48ed8ea@googlegroups.com> Subject: Re: class wide iterable (and indexable) From: George Shapovalov Injection-Date: Fri, 04 Jan 2019 12:20:26 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:55190 Date: 2019-01-04T04:20:25-08:00 List-Id: > I am using interfaces extensively and in real programs. (:-)) Nice to know I am not such an exception :). > In real programs dispatch is rare, thus there is no overhead. I don't=20 > know which overhead Randy meant, though. Maybe, space overhead? That is= =20 > not nearly close to what generics produce in GNAT... Ah, good. I was trying to imagine how it could be so bad indeed. So, thanks= for confirming the sanity :). >=20 > >> Perhaps if Ada allowed multiple controlling parameters of different ta= gged [..]=20 > Huh, it would render generics useless!=20 How so? Perhaps in the sense that the same effect could be achieved by diff= erent means, that yes of course. But anything Turing complete can emulate a= ny other such thing anyway (albeit often grossly ugly). So, there is no nee= d for anything but 4 base ops anyway :). But generics would retain their us= e as a concise and clear form of, well, generics in any case. One of=20 the main features that make Ada stand out is its expressivity, and clear a= nd powerful generics are an important component here IMHO (at least as they= were intended - to clarify further comments). Especially compared to glori= fied macros in the form of templates in C++ or similar. Having had to fight= those, it is easy to appreciate clear (and much more verifiable) form of g= enerics in Ada after that.. > >> But with the existing Ada rules, > >> interfaces can only be useful if the profiles are fixed (non-generic) = and > >> are still reusable -- that doesn't happen that often. >=20 > Combination of interfaces and generics is the only way to handle many=20 > situations in practice. Actually it is a very frequent pattern when a=20 > base type is a formal parameter of some generic used to derive from it=20 > while adding implementations. Ah, I see now what you have meant about generics becoming useless. Yes, tha= t use case would indeed be much alleviated by a less limited multiple inher= itance, although that could create many more safety concerns I imagine (eve= n though this field has been heavily trotted by now, with major languages a= llowing "full" multiple inheritance settling on specific and very strict ru= les of field/method lookup, most commonly based on topological sort).=20 > > Besides the optimization issues, which are invisible to end user and of= ten are not so critical, I fail to see how generics would affect logical st= ructure of the program in this case. >=20 > As all preprocessors generics tend to destroy any logic and every design= =20 > by muddying mapping of the program types and modules to the=20 > problem-space entities. This would be the case with e.g. C++ templates, where it is often indeed ne= cessary to meddle with "processed code" to comprehend what is going on and = make sense of the 100-line long error message(for a single line of code) sp= it out by the compiler. Fortunately this is much more rare with Ada. Althou= gh this case is seemingly indeed one of those, so there then :). > > Besides linking various type hierarchies together, interfaces are good = for containing common code that does not care about specific data storage d= etails. >=20 > No, interfaces cannot contain common code except for class-wide one.=20 Yes, I have meant the class-wide methods here of course. Although I must ad= mit I wished more than once that non null/abstract methods that could be in= herited and overriden are allowed. Of course they could only reference oth= er methods (as the data is non-existent at this point), all eventually oper= ating on the abstract/null primitives that are essentially "axioms" of the = specific interface. But thus one could provide meaningful abstracted functi= onality that could be overriden in a sane way, removing the need for vario= us tricks, one of which you show in your comment.=20 Perhaps allowing this and stopping at interfaces (vs full type multi-inheri= tance) would make for a sufficient but safe type system.. > > How generics complicate the issue? >=20 > It is hideous. Well, in view of this part of discussion I must agree on this aspect, even = if the intended use of generics is rather elegant (compared with most exist= ing alternatives in other languages). But alas, while it is fun to discuss language design issues, this grew way = out of proportion with relation to the original issue by now :). Still, thank you everybody for the informative answers and for the possibil= ity to learn new things about inner workings of gnat.. George