Re: Ada OOP alternatives?

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

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcc63r3pdi7.fsf@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?

I believe that pragma Inline should either not exist at all (in favor of a 
more general way of specifying optimization parameters), or just be a hint 
to the compiler. It should surely should not have a semantic effect of any 
kind.

And I agree with you about the multiple modes. Indeed, the grand design for 
Janus/Ada is exactly that. The "conventional compilation" mode is for 
getting executables fast (for debugging and development). The "production 
compilation" mode would (it never got built because we didn't have enough 
memory back then) push all optimization and code generation as late as 
possible - at least as late as link-time. (Aside: that's effectively what 
Java does, although Just-in-Time compilation probably is going too far for 
many uses.)

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

You need to know a lot more than just the size of the object in order to 
create a non-contiguous object: for instance, you need to know the 
dependences of the subparts on the discriminants in order to allocate memory 
for those subparts. That has to be done before construction, else you won't 
have anywhere to evaluate the constructor expressions.

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

Here I think I disagree, at least to a point. A good language (intended to 
have a long life!) allows a broad array of potential implementation 
strategies, because things that seemed like a good idea in 1980 aren't 
today.

To take a specific example. You've been talking about incremental 
compilation. One thing that Pascal always used to harp on is how much that 
depends on not breaking privacy. It would be trivial to define a language so 
that incremental compilation wasn't practical; but it surely would still 
have "one viable implementation strategy".

So I think a good language design has to go beyond "one viable 
implementation strategy" to allow as many as practical. (Of course, there 
better be at least one implementation available, and knowing the existence 
of that is important.)

                                           Randy.