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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b6e97963d32ee242 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-02 02:11:47 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!feed.news.nacamar.de!news.netplace.de!news-FFM2.ecrc.net!news.iks-jena.de!not-for-mail From: Lutz Donnerhacke Newsgroups: comp.lang.ada Subject: Re: The old "Object.Method" syntax debate Date: Mon, 2 Jun 2003 09:11:46 +0000 (UTC) Organization: IKS GmbH Jena Message-ID: References: <254c16a.0305210726.485125de@posting.google.com> <3eccdf77$1@epflnews.epfl.ch> <3ecdd296$1@epflnews.epfl.ch> <3ED056CB.8000200@attbi.com> <3ed33506.7272397@news.btclick.com> NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1054545106 6916 217.17.192.37 (2 Jun 2003 09:11:46 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Mon, 2 Jun 2003 09:11:46 +0000 (UTC) User-Agent: slrn/0.9.7.4 (Linux) Xref: archiver1.google.com comp.lang.ada:38318 Date: 2003-06-02T09:11:46+00:00 List-Id: * Randy Brukardt wrote: > Lutz Donnerhacke wrote in message ... >>* Dmitry A. Kazakov wrote: >>> Lutz Donnerhacke wrote: >>>> Problem 1: Pointer of component => Pointer to aggregate >>> >>> Solved with MI = Class-wide pointer -> Dispatch >> >>I do not have tagged data types. Due to hardware design requirements I can >>not have tagged data types. > > Speaking for myself, (and not the ARG!), I have a very big problem with > people who say that we should change the language, because they cannot > (or are unwilling) to use the features already in the language that can > solve the problem. I solved the problem within the current language. This code is unrealiable and part of the reasoning to suggest the new feature. You may discard the existing code and complain about the missing one. It does not bother me. > That is especially true in the case of tagged types and finalization. We > see a lot of proposals which essentially are providing some of the > functionality of these features without actually using them. The problem > is that such things complicate the language without adding anything for > the majority of users. Moreover, such proposed features typcially have > similar overhead and implementations to the existing features. So, if > the requestor has a valid reason for not using the feature (such as too > much overhead), they probably could use the proposed feature either. The reasoning behind the requested feature is simple: Only the compiler knows how the data types are layouted on a given instantiation. There is no way to determine the layout without very dirty tricks, I do not want to apply without any need. Currently I use those tricks. YMMV. > OTOH, if the requestor's reason is just FUD (fear, uncertainty, > doubt) -- which I see a lot in embedded Ada programs -- it would be a > lot cheaper for everyone to educate them to eliminate the FUD than to > change the language with the associated costs for everyone. FUD is not on my boots, isn't it? > Of course you can have tagged data types. You may not be able to have > them in your hardware interface packages, but certainly you can use them > in the bulk of your code. Why not? You can give rep. clauses on them; > you can even lay out the type such that everything except the tag > matches the hardware representation. (That is what we did in Claw for > the bitmap types. That allowed us to cleanly model the numerous > representations without dozens of case statements.) Of course I can do this. But for what purpose? It would be much more efficient to write an inferfacing package copying the exact memory layout from a specialized data type to the tagged one without representation clauses. > of SPARK have little to do with the needs of the next generation of Ada > programmers. I do not talk about SPARK. Not here.