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!postnews.google.com!y38g2000hsy.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Ada OOP alternatives? Date: Tue, 22 Jul 2008 13:32:20 -0700 (PDT) Organization: http://groups.google.com 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: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1216758740 27095 127.0.0.1 (22 Jul 2008 20:32:20 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 22 Jul 2008 20:32:20 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: y38g2000hsy.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:1257 Date: 2008-07-22T13:32:20-07:00 List-Id: On Jul 16, 6:36 pm, Robert A Duff wrote: > "(see below)" writes: > > On 17/07/2008 01:05, in article wcc3am9gytt....@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. > And I think incremental compilation can be a big win. You know, I'm still dreaming of the day when we can get rid of our current "object file" model of compilation, or whatever it's called, in which we assume that the compiler is going to compile individual library units into object code almost completely, so that the process of building the complete executable from all of its compilation units (linking) consists mostly of just patching addresses. This technology has been around for a long time, but why are we still stuck with it? It seems to me that it ought to be possible to have a compiler that compiles individual source files into some sort of "intermediate" representation that is not quite machine code, and then when the complete executable is built, the intermediate code is then used to generate the actual code. This final process wouldn't be as fast as a linker that just patches addresses; for a large program, when one compilation unit changes, the final build would have to reprocess all of the compilation units that go into the program. But it seems like it ought to be possible to design an intermediate representation that could be converted fairly easily with a minimal amount of processing, so that given the speed of today's computers (as compared with 1983), this extra processing wouldn't be much of an issue. This would make it possible to dispense with private parts and put all of the "private" stuff into package bodies. And if the language rules make privacy leakage impossible, then all legality errors would still be caught at "compile" time; there shouldn't be any case where an error isn't found until "final build". But I realize that I'm just dreaming... -- Adam