Re: Ada OOP alternatives?

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> I used to review C code that packed almost 80% of executable code in the
> header files... (:-))

What fun!  ;-)

>> I want separate specs and bodies, not for the compiler's benefit, but
>> for the programmer's benefit.  I want to be able to read a concise spec,
>> without having to wade through the entire body.
>
> There are two problems with that. The first one is that the difference is
> not obvious. Why legality check is less than "full compilation", so that
> the delta cannot be left for the binder/linker. The second one is that if
> the delta is sufficient, then the reader should probably become aware of
> it. In short, it is difficult to drive a margin.

I don't understand.  To (e.g.) determine whether a procedure call is
legal, you need to know its name, parameter types, etc.  (Whether "you"
is the human or the compiler.)  To generate code, you need to know more
-- which register to put the parameter in, etc -- and if inlined, what
code is in the body.

>> The compiler should check legality without looking at other bodies.  But
>> it should look at bodies when generating code (at least if optimization
>> is turned on).
>
> But what would you do with dynamically linked libraries, remote partitions
> and other lately bound stuff?

I don't see what that has to do with organization of the source code.
These things are implemented using "extra" levels of indirection at run
time.  E.g. you can't very will inline a call in an executable, and then
expect that updating a shared library used by that executable will
update the call by magic.  So don't inline across such boundaries.

>... I think that the time of monolithic systems
> is gone.

I don't think so.  Certainly some embedded systems are monolithic,
and should be.

- Bob