Re: Tagged type more type safe than access to subprogram ?

["Hibou57 (Yannick Duchêne)" <yannick_duchene@yahoo.fr>]

On 28 oct, 09:55, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> An access to subprogram is a poor-man's closure. Let's ignore "access" part
> and consider a pure downward closure (as it should have been in Ada).
“ As this should have been in Ada ” ? What were you to mean ? I've
always though real closures are not possible with such structures as
Ada provides, except at package level — which is especially the case
when a package can have multiple instances... but only at package
level. Isn't it ?

> I argue that a helper type with an abstract primitive subprogram is safer
> than a closure, both safer and type-safer.
>
> The general safety comes from the fact that a closure brings a context with
> it, which an object normally does not. An abstract type is better
> encapsulated and there is less chances to run into occasional side effects.
> Even if the side effects are desired I would argue that it is better and
> safer to limit them to the object rather than to the closure's context. The
> crucial point is that closure's effects are "there", while effects on the
> object are localized to the object's state, there are "here", at the call
> point.
>
> The type safety is gained through different types derived from the abstract
> parent. There might be no difference at the caller side, e.g. whether you
> mistakenly call to the closure C1 instead of C2, or mistakenly pass an
> instance of S1 instead of S2 (both from the S'Class). Yet it is type safer
> with regard to the parameters required to construct S2. Its constructor can
> have a different signature, so that the parameters you pass in order to
> create it were different from S1.

If I attempt an abstract of your words, and if I've understood you in
a right way, it could be : tagged types are safer than accesses to
subprograms, because the abstract method of a tagged type is always
associated to a suitable context, unlike subprogram, with which ones a
single error is immediately turned into a double error — the one about
the subprogram and the one about the closure which comes with the
subprogram reference.

This is relevant, indeed.

Now I see the deal much better (providing I'm OK with my
understanding).


I would like to just add two other notes, about flexibility (not
safety) : the first one, I think its a good idea to add a Ready
function (returning Boolean) to the tagged type, because the tagged
type may be extended in a way where it needs setup (useful for peoples
who like to add Eiffel-like precondition to their specifications).
This seems general enough to me to add this function to any tagged
type which is intended to act as an abstract method (and to add an
initial default implementation which always return True). And then,
about implementation now : if an abstract method is concerned by
performance, it is possible to add an alternate batch version belong
to the primary abstract method (to run the method on a sequence of
parameters, either as input or output). This is a good idea to add it
to the same tagged type, as it is deeply related to the “ normal ” (un-
batched version) of the abstract method (deeply related in many ways,
such as required internal data to work, setup, shared part of
algorithm, etc).

This is another argument pleading in favor of the provided flexible of
tagged types over access to subprograms.