Re: Ada OOP alternatives?

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

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wccy741fg0z.fsf@shell01.TheWorld.com...
>> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>>
>>> On 17/07/2008 01:05, in article wcc3am9gytt.fsf@shell01.TheWorld.com,
>>> "Robert A Duff" <bobduff@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.
>
> 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