Re: What would you like in Ada202X?

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:11hojzrgyl24o$.1rbxahkuoy4ab$.dlg@40tude.net...
> On Thu, 26 Apr 2012 18:58:06 -0500, Randy Brukardt wrote:
...
>> I've concluded that I'm pretty much against all forms of MI.
>
> Do not both Integer and Float implement "is private", T'Image, X'Size? MI
> is all around you without any tagged types, you cannot get rid of it. You
> sweep it under the carpet and pretend it does not exist.

These examples might be "M" (multiple), but they don't represent "I" 
(inheritance) -- you can't (and shouldn't) inherit these things other than 
linearly.

Note that the things that you mentioned are called "categories", 
"characteristics", and "aspects", respectively, in Ada. You could put them 
all under the unbrella of "properties", but what's important here is that 
the rules are necessarily different for each grouping. For instance, 
"categories" are not necessarily inherited, and can be view-specific (like 
"is private"). There is no way to unify these rules (we tried for Ada 2005 
when we discovered they were poorly defined), because the needs are 
different.

I could imagine extending the "aspect/attribute" feature to user-defined 
aspect/attribute pairs; that would properly mimic the idea of specific 
properties applying to particular types. That's all interfaces really gives 
you anyway, in a much more complicated way.

>> Which I realize
>> is probably too strong, but surely Interfaces isn't it. I'm definitely
>> against any mechanism that you can only use once, which is the way a
>> particular interface works. That leads to silliness like the "no hidden
>> interfaces" rule (because otherwise you could destroy privacy by adding 
>> the
>> "right" interface; alternatively, you could destroy everyone's sanity by
>> determining what routine to dispatch to by what visibility you have).
>
> That is because the broken Java model was deployed. Look you cannot make a
> type non-limited by adding "private" (=copyiable) interfaces. There is no
> problem, except for fighting shadows.

There are of course problems with any model, and they're a lot more than 
shadows. If you have a copyable interface, you of course might copy it -- so 
what happens if the actual object is a limited type? Runtime failures are 
ugly at best, and go completely against the grain of Ada's philosophy of 
preventing errors at compile-time.

If you're willing to abandon all compile-time checking, then of course there 
are no problems (and probably no programs that work, either). That's not 
Ada.

In any case, interfaces is barely compatible with Ada, and a more general 
scheme is impossible -- it would be completely unimplementable. You'd need 
to start over with a new language and new, from scratch implementations 
(which are not happening for Ada).

                                    Randy.