Re: Your wish list for Ada 202X

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 14-04-15 03:08 , Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
> news:br07nkFnvrbU1@mid.individual.net...
> ...
>> (This is why I don't understand your and Randy's abhorrence of
>> re-dispatching -- to me, there is no basic difference between
>> dispatching calls in class-wide operations, and re-dispatching calls in
>> primitive operations.)
> 
> I don't think it is a good idea to assume that Dmitry and I have the same 
> opinion on anything, even if the result appears to be the same. :-)

I think I knew that... apologies if I implied differently (I see the
smiley, thanks for the forbearance).

> I view dispatching operations as the low-level primitives of a type, while 
> class-wide operations (which actually involve dispatching) as higher-level 
> operations of the type.

In this you and Dmitry agree, it seems.

In an earlier reply to Dmitry, I also agreed that class-wide operations
are higher-level than primitive ops, but having thought a bit more, I
want to modify that statement. Some of my class-wide operations are,
rather, so fundamental for the class that I make them class-wide because
I see no need to ever override them in any derived type of the class.

But I'm not sure if we can equate "fundamental" with "low-level",
architectural analogues notwithstanding ;-)

> As such, a re-dispatching call means that there is 
> some sort of abstraction inversion going on, and that's usually (but not 
> always) bad.

As I replied to Dmitry, my primitive operations tend to be layered, and
redispatching usually goes from a higher-level to a lower-level
operation. So I don't see this as abstraction inversion.

> Dispatching operations necessarily have weaker contracts than statically 
> bound calls, and that is especially important for "contracts" that can't be 
> described in Ada and thus can't be checked (either statically or 
> dynamically).

Hm, I'm not convinced of that. To me, the informal contract for a
dispatching operation Foo is "implements the Foo operation as specified
for the class and as appropriate for the actual type". Of course these
specifications are given in comments.

I don't see the "necessarily ... weaker" for the more formal contracts
either. Yes, for a dispatching call there are more possible callee
operations (implementations) to check against the contract, but the
general contract (as experienced by the caller) can be the same for all.

> After all, most extensions are created by someone other than 
> the originator of the original class,

Not (sadly) the case for my applications. But sometimes years go by
between the definition of the class and the addition of a derived type,
so memory can play tricks, and I have had a few hiccups in that area.
But not many, perhaps thanks to my obsessive commenting.

> so violations of those implicit 
> contracts are bound to happen. (Errors happen any time humans are involved!) 
> Thus, you have much more confidence in operations that don't involve 
> re-dispatching -- as a practical matter, it is a lot easier to debug 
> statically bound calls rather than dispatching ones.

I try to make my contracts explicit in comments.

All I can say is that my experience does not agree with what you say.
But the volume of my programming is not so large as to make a good
empirical study.

> Finally (really a restating of the last point), I find that it's fairly easy 
> to ensure that all of the primitive operations of a particular type have the 
> same world-view. That's not as true when some of the operations are assuming 
> the object is of type T, and some are re-dispatching to some TT derived from 
> T -- I've found many instances where some predicate of TT gets a different 
> answer than the same predicate of the same object viewed as a T. That sort 
> of things leads to all kinds of bugs, because not all of those predicates 
> are explicit in the code (even as statically bound calls).

I'm not disputing your experience, but I haven't experienced the same.
Perhaps there is some difference in our application areas that modulates
the risks and benefits of redispatching.

> This last issue doesn't arise for a class-wide operation, where every call 
> is going to look at an object of TT as type TT.

Except if TT inherits some operation from T, because then that operation
looks at the object as type T. (I know that from the language-semantics
point of view the inherited operation acts on TT, but the programmer
wrote its code with T in mind.)

If redispatching is suspect because it breaks the assocation of an
operation with a unique type, then inheritance of operations must also
be suspect, for the same reason.

I suppose one could forbid both inheritance and redispatching. That
would be a major departure from traditional object/class-oriented
programming.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .