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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Received: by 2002:a6b:8e83:: with SMTP id q125mr46517349iod.9.1546560022089; Thu, 03 Jan 2019 16:00:22 -0800 (PST) X-Received: by 2002:a9d:148:: with SMTP id 66mr1000638otu.5.1546560021739; Thu, 03 Jan 2019 16:00:21 -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.215.MISMATCH!k10no25645itk.0!news-out.google.com!v71ni104ita.0!nntp.google.com!q69no25858itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 3 Jan 2019 16:00:21 -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: Subject: Re: class wide iterable (and indexable) From: George Shapovalov Injection-Date: Fri, 04 Jan 2019 00:00:22 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:55185 Date: 2019-01-03T16:00:21-08:00 List-Id: > Vectors support both indexing by an integer and reference via a cursor.= =20 > Usually, the List container is a better example for cursor operations=20 > because it doesn't have the confusion of (direct) indexing involved. Ah, right, that Ada gem I initially read was indeed operating on linked lis= ts. This is why it only implemented one method. But I needed the indexing t= oo in my case, which is attached via different aspects. So it all seemed to= correspond so far and even work, as long as I did not try to do an "of-loo= p" over class-wide var (derived types worked fine). > Because that would substantially harm ease-of-use. You'd have to write=20 > multiple instantiations to create any container. It's annoying enough (to= =20 > some, at least) to have to write one. Well, I rather consider an extra line of (typically elementary) code a smal= l price for versatility, but then apparently opinions vary a lot on this on= e :).=20 But the next point is more essential: =20 > Besides, interfaces are (nearly) useless (and especially so for this sort= of=20 > usage, where some part has to be generic). They add a lot of runtime=20 > overhead that doesn't actually get used in real programs. Really? I did not consider this. I thought there would be no extra overhead= , as the compiler should be able to select appropriate constructs as needed= and optimize away with higher -OX. But indeed, in case of generics it woul= d likely produce extra code blobs.. Oh, well, looks like I may be better of= f with a more simplistic design, using getters/setters and iterating over t= he provided index type (which is needed there anyway). Looks like that woul= d be more efficient with generics, even though less elegant. Those extra ge= t/set qualifiers instead of direct indexed access look a bit annoying :). B= ut this is really a minor issue. And at least I learned a thing or two abou= t inner gnat workings on the way :). > Perhaps if Ada allowed multiple controlling parameters of different tagge= d=20 > types, then there might be more use. Funny that you mention this one. That was my thought exactly at one (comple= tely unrelated) point - that unlike most other languages, Ada has the synta= x that could naturally allow multiple controlling parameters, and that coul= d be a really powerful type composition feature.. A pity this was not done = so, that would be a fun feature. But then I do realize that it takes a spec= ial kind of thought organization (more pure math than typical procedural id= iom most programmers follow) for the developer to feel comfortable with suc= h a feature. With most other common languages not having even a provision t= o formulate such a structure, most developers would be at a loss to compreh= end what is even proposed in the standard I am afraid (at least from what I= could observe). So I can see why this was not seriously considered. Plus t= hat would give a huge potential for abuse - just think of all the possible = combinations multiplying complexity, having to turn simple dispatch tables = into multidimensional (and very sparse) arrays.. Btw, I'd rather say that this, and not the (not so evident) observation of = extra overhead is the main reason for: > For example, we=20 > did do what you suggest for the queue containers. Irrelevant thought: tha= t's=20 > probably why I have yet to hear of anyone actually using one of them. :-)= =20 That, and (more essentially) that the standard Ada.Containers are sufficien= t for most situations, as you point out elsewhere. > But with the existing Ada rules,=20 > interfaces can only be useful if the profiles are fixed (non-generic) and= =20 > are still reusable -- that doesn't happen that often. Why?=20 Besides the optimization issues, which are invisible to end user and often = are not so critical, I fail to see how generics would affect logical struct= ure of the program in this case. Besides linking various type hierarchies t= ogether, interfaces are good for containing common code that does not care = about specific data storage details. How generics complicate the issue? (at= the level of program logic, not underlying code - most apps away from crit= ical domains do not care about 2x size or loss of 10% time efficiency away = from critical loops, if that allows to reuse well tested code). In fact it = seems to me that generics fit very well with such development model..