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-05-30 13:12:09 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!news-feed.riddles.org.uk!sn-xit-03!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: The old "Object.Method" syntax debate Date: Fri, 30 May 2003 15:13:16 -0500 Organization: Posted via Supernews, http://www.supernews.com 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> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:38152 Date: 2003-05-30T15:13:16-05:00 List-Id: 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. 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. 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. 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.) It's annoying that SPARK doesn't support dynamic dispatching, since it is relatively easy to describe the requirements (essentially that any overridden potentially dispatching routine have the same set of pre-conditions and post-conditions as its parent). But the requirements of SPARK have little to do with the needs of the next generation of Ada programmers. Randy.