Re: Generic procedures and their parameters

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

On Thu, 07 Sep 2006 08:48:21 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
> 
>> But this all is independent on the question whether interface and
>> implementation inheritances are different things. They are not. 
> 
> Suppose I have some complex number type C
> having a lengthy division operation that requires
> auxiliary components in the implementation.
> 
> Now I want a type of complex numbers just like C
> but without a division operation.

Operation disallowing, it is an interesting beast...

> One way to do so might seem to inherit a D from C,
> and clear the division operation,
> 
>    type C is tagged private;
>    ...
>    procedure division(a, b: C; result: in out C);
> 
> 
>    type D is new C with private;
>    ...
>    overriding
>    procedure division(a, b: D; result: in out D) is null;
> 
> (Is there anything better than null BTW? It won't remove
> division from D's interface...)

It cannot, because D is in C'Class. You need "/" there (minimally as a slot
in the dispatching table), otherwise some class-wide operations of C would
become erroneous. Actually "override with null" = "override with raise
Some_Error." In static cases the compiler can catch it, but in general case
it cannot, provided that T'Class exists. [And it shall, IMO, exist for all
types, maybe for T'Class itself too (:-)) ]

> This will leave the auxiliary components of C in D.
> 
> But couldn't I do better? For example, by declaring
> the interface I want, and then requesting that the needed
> operations be "extracted" from C, dropping the division
> stuff (provided there is a way to mark components as being
> needed by only some set of operations.)

This is quite straightforward. You declare somewhere an interface without
division (Ring). Then you inherit D's interface from Ring and do D's
implementation from C. That should work similarly to Ada's implementation
by renaming and matching "is <>" formal generic subprograms. So C."+" would
implement D."+" inherited from Ring."+", while C."/" will be dropped,
because there is no Ring."/". Basically, it could be just an automated
delegation.

> I will loose view conversions to C.

Publicly, privately you can still have them. It makes little sense not to
have them privately, because "/" can be still reachable. You never know, if
"+" does not call it.

> But if that is what I want? Just a composition of
> the interface I need in some scope?

View conversions and other conversions (and attributes) are in fact
primitive operations. As such they are a part of the interface. There is no
magic in, if you have a different interface, then conversions are
automatically different.

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