Re: Avoiding dispatching in procedure's with classwide types

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

On 07/06/2016 04:23, Jeremiah wrote:

> So my question is if the method used in Copy_Value_1 considered a
> no-no or since it bypasses dispatching in favor of directly copying the
> values in a procedure that takes a class wide type? Or is it ok since
> there is no guarantee to what the internals of the Copy_Value_1
> procedure are? My gut is it is bad form, but I wanted to know if I was
> just over thinking it.

The answer depends in your example on whether it represents a full 
multiple dispatch or not. Assignment is multiple dispatch by definition. 
So the implementation you presented is in general wrong. But, *IF* one 
of the types involved is final and does not have any descendants the 
implementation is OK.

In the declarations provided, both types are tagged and thus there is no 
hint that one of them were final. Therefore in order to make it right 
one of the types must be made, at least, publicly untagged.

There is an Ada design flaw that privately tagged types easily leak into 
public declarations, so, possibly, the tagged type should be wrapped 
into a non-tagged record.

> As for why I would think it would improve performance:

No. Multiple dispatch should be far faster that its cascaded poor-man's 
emulation through single dispatches, in case it is really a multiple 
dispatch.

> GNAT doesn't
> tend to optimize out dispatching calls

There is no need to "optimize" them. The design of dispatch in Ada is 
such that when you could optimize it, there should be a specific type 
already and the call non-dispatching. All "optimization" is already 
here, static on the language level. Anything else, e.g. re-dispatch 
cases are software design bugs, IMO.

> But it might also leave the procedure
> open to bugs on derived children?

If you violate typing then yes. Assignment is an MD operation. Its 
implementation as a non-MD operation violates typing and thus is open to 
any bugs.

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