Re: Legit Warnings or not

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:gfjkj1eowd8x.1q86rn9zvkfd.dlg@40tude.net...
> On Fri, 29 Jul 2011 19:17:25 -0500, Randy Brukardt wrote:
...
>> Interfaces require multiple inheritance. Multiple inheritance is
>> unimplementable (at least efficiently). It's completely unimplementable 
>> in
>> Janus/Ada which is based on fixed, statically sized objects and 
>> components.
>> (Generic code sharing is a lot easier.)
>
> 1. Ada 2005 has interfaces.

Ada 2005 interfaces are unimplementable in Janus/Ada. (That's a tiny bit 
strong, there is a way to implement them, but no one would ever want to use 
the result.)

> 2. The case I gave is fully static, without classes (of arrays or 
> records).
> This is not a dynamic interface it is just same thing as "type X is
> private;" Private and limited private were interfaces already in Ada 83.

If you have a generic sharing compiler,  there is nothing that is not a 
dynamic interface. *All* properties of a type are dynamic.

The presence or absence of array manipulations is pretty much the only 
exception, which makes it reasonably efficient. Changing that would make a 
decent implementation impossible.

This certainly could be done in an all-new language (which wouldn't have the 
generic baggage of Ada), but not in Ada.

> 3. It was you arguing for objects which size were indeterminable and
> components dynamically allocated. And now?

No, I was arguing for "non-contiguous objects". I *am* guilty of mixing up 
Janus/Ada terminology with Ada's, however; for Janus/Ada, all top-level 
objects are contiguous and statically allocated. They may, however, have 
implicitly managed sub-parts that are neither. That's why Janus/Ada 
considers the array descriptor (which is static sized) the object and not 
the data. That's not quite the meaning of "object" in Ada, and presumably 
you read it to mean something closer to that definition - sorry.

So far as I can tell, it is impossible to come up with anything reasonable 
which would allow multiple inheritance in this scheme, because the compiler 
has to know in advance how many parts there are and where to find them --  
and that is not possible with multiple inheritance.

 > 4. Why a built-in implementation of array of S'Class (what you seemed to 
be
> arguing for) should be easier/more efficient/more compatible to Ada than 
> an
> implementation trough Ada.Container only publicly visible as an array?

There is no new magic needed to allow S'Class as a component type -- only 
the removal of a single legality rule (much like Ada 2005 eliminated the 
library-level requirement on derived tagged types). That means it fits much 
better into the existing structure - from a user perspective, nothing 
significant has changed.

New kinds of interfaces ("gazebos", you once called them), are a much more 
significant change to the structure of the language. They have an effect on 
both user understanding *and* and implementations. These sorts of things 
have a much higher bar to cross.

Besides, Ada 2012 already has user-defined indexing. I find it hard to 
imagine that we'd add a second way to do that.

                                      Randy.