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-Thread: 103376,8591be732d0fce98 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newspeer1.nac.net!newspeer.monmouth.com!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Ada OOP alternatives? Date: Fri, 18 Jul 2008 08:45:20 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <462e0cf4-1d53-4918-b30b-dd3d8df90f1b@p25g2000hsf.googlegroups.com> <487d9636$0$6543$9b4e6d93@newsspool3.arcor-online.net> <6e5uq2F5g7n6U2@mid.individual.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1216385120 1277 192.74.137.71 (18 Jul 2008 12:45:20 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Fri, 18 Jul 2008 12:45:20 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:1G7yGuaj+9W7+F2yU3IHBKLakUU= Xref: g2news1.google.com comp.lang.ada:1207 X-Original-Bytes: 4784 Date: 2008-07-18T08:45:20-04:00 List-Id: "Randy Brukardt" writes: > "Robert A Duff" wrote in message > news:wccy741fg0z.fsf@shell01.TheWorld.com... >> "(see below)" writes: >> >>> On 17/07/2008 01:05, in article wcc3am9gytt.fsf@shell01.TheWorld.com, >>> "Robert A Duff" wrote: >>>> I'd still rather eliminate private parts altogether. >>> >>> How would you do that while allowing ADT clients to access objects >>> directly >>> (i.e. not via a pointer a la Java)? >> >> I'd have the compiler take a peek at the body when compiling the client. >> After all, that's what Ada compilers already do for pragma Inline. > > That's what *some* Ada compilers do. Personally, I think that violates the > spirit of Ada (Ichbiah version) by adding unnecessary compilation > dependencies. Indeed, I think the whole design of pragma Inline is wrong in > Ada. Not sure what you mean. In order to inline a call, the compiler has to look at the body of the callee -- no way around that. And when the body of the callee changes, the code at the inlined call site needs to be changed. It's certainly annoying when unrelated changes in the same file where the inlined body lives trigger recompilation of the world. And that is avoidable via incremental compilation. As to the inline violating spirits, Ichbiah presumably designed whatever "spirit" you mean, and also designed pragma Inline, so are you saying Ichbiah violated the spirit of Ada? It's certainly possible... Anyway, what's your idea about how the design of inline should be? > ... >> We're just talking about the size of the type, really -- you say >> "access objects", but clients can't access the record components >> of a private type -- all they can do is declare objects and >> pass them around. > > Ugh. That's surely not true, either, unless you insist on allocating all > objects contiguously. I'm confused. I don't see how allocating noncontiguously contradicts what I said -- which part were you referring to. >...And I see absolutely no reason to do that in > general -- the limitations that it puts on the programmer are unnecessary > and impossible to see. (Particular cases for particular [usually > safety-critical] programs are a very different story of course -- but > safety-critical users are going to put all kinds of restrictions on > themselves which don't mean that they are a good idea for the rest of us.) I agree with that general point. > There are a lot of different ways to design a compilation system, and one > thing we've clearly learned from the ARG is that making any sort of > assumptions about how "everyone" is going to implement something are almost > certainly wrong. Well, I suppose so, but "everyone" has to implement whatever language they're implementing in a way that is correct. (E.g. using a one-pass, bottom-up overload resolution algorithm is just plain wrong, for Ada.) And it is the responsibility of the language designer to make sure that there is at least one viable implementation strategy -- not to make sure that every imaginable implementation strategy is viable. >... Language design has to be more general than that (unless > you are willing to have a sole-source language like Eiffel, and those are > almost never interesting). I think Eiffel has more than one implementation. - Bob