Re: Your wish list for Ada 202X

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 11 Apr 2014 21:04:58 +0200, Niklas Holsti wrote:

> On 14-04-10 17:31 , Dmitry A. Kazakov wrote:
>> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote:
> 
>   [snip]
> 
>>> We don't want "type-specific" implementations of most things -- that's just 
>>> adding a maintenance headache where one isn't needed.
>> 
>> It is need for
>> 
>> 1. safety (because you statically know that certain specific operation may
>> not fail, while class-wide operations can)
>> 
>> 2. efficiency
>> 
>> There is no maintenance overhead whatsoever. Here is the proof. Let you can
>> provide a generic implementation (as you suggested), then this
>> implementation can be safely inherited. 
> 
> If you change a class-wide operation to an inherited (i.e. primitive)
> operation, you have to change its dispatching calls to redispatching
> calls, if you want the same behaviour as for the class-wide operation.

No. I meant that the behavior of class-wide operation was defined = there
were no re-dispatch to operations that could be overridden to some
unanticipated behavior.

If not, then Randy's argument about maintenance is automatically false.

> But (based on your earlier messages) you refuse to use redispatch, so
> this change is not possible for you. Your proof fails when limited to
> your subset of Ada, where redispatch is absent.

The premise of the proof was that the operation's behavior was
well-defined. Otherwise, it is already unmaintainable.

Regarding use cases where re-dispatch comes in question, which certainly
exist, I think that from the safety and maintenance point of view, the type
system should provide means of body composition beyond simple inherit vs.
override. We know, for example, that constructors (initialize) and
destructors (finalize) require other means of composition. More elaborated
composition tools should eliminate re-dispatch (and most class-wide
operations) => give safety and maintainability.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de