Re: Ada OOP alternatives?

[Jeff Koftinoff <jeff.koftinoff@gmail.com>]

On Jul 22, 1:32 pm, Adam Beneschan <a...@irvine.com> wrote:
> On Jul 16, 6:36 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
> wrote:
>
> > "(see below)" <yaldni...@blueyonder.co.uk> writes:
> > > On 17/07/2008 01:05, in article wcc3am9gytt....@shell01.TheWorld.com,
> > > "Robert A Duff" <bobd...@shell01.TheWorld.com> 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

FWIW, the intel C++ compiler (icc) stores only intermediate meta-code
in object files and library files. All generation of assembly code and
optimizations, including inter-program inline optimizations, occur at
link time!

--jeffk++
www.jdkoftinoff.com