Re: Ada OOP alternatives?

["Randy Brukardt" <randy@rrsoftware.com>]

"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.

...
> 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. 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.)

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. 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).

                                                       Randy.