Dispatching operations

Dispatching operations

[Maciej Sobczak]

Hi,

Consider <http://www.adaic.org/standards/95aarm/html/AA-3-9-2.html>, 
example from 20.c to 20.f.

It is said that the following call:

P2.Op_B(Arg => X);

is non-dispatching.

My confusion is that Op_B is private in P2. X is declared in P2 as well. 
In the above call, I'd expect P2.Op_B to be called (which is actually 
the case), but since everything is known statically, then I'd expect as 
well to get compile-time error due to the fact that P2.Op_B is private.

In other words: how can I get compile error when calling private P2.Op_B?
If it's not possible, what's the point in making it private?


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Dispatching operations

[christoph.grein]

> My confusion is that Op_B is private in P2. X is declared in P2 as well.
> In the above call, I'd expect P2.Op_B to be called (which is actually
> the case), but since everything is known statically, then I'd expect as
> well to get compile-time error due to the fact that P2.Op_B is private.
>
> In other words: how can I get compile error when calling private P2.Op_B?
> If it's not possible, what's the point in making it private?

It's irrelevant whether an operation is overridden visibly or
privately. Always the overriding operation is called, even if not
visible at the place of the call.

There are very subtle effects when overriding privately:

package P1 is
    type T1 is tagged null record;
    procedure Op_B(Arg : in T1; Parm: Integer := 5);
end P1;

with P1; use P1;
package P2 is
    type T2 is new T1 with null record;
private
    procedure Op_B(Param : in T2; Parm: Integer := 0);
end P2;

When calling P2.Op_B, it depends on the local visibility at the place
of the call which default for Parm is used and which name you have to
use in named association for the first parameter.

When the private part of P2 is hidden, Op_B (Arg => X) means Op_B (Arg
=> X, Parm => 5). You do not see the new name of the first parameter.

When the private part is visible, Op_B (Arg => X) is wrong; you have to
write Op_B (Param => X) which means Op_B (Param => X, Parm => 0). You
have to use the new name of the first parameter.

Re: Dispatching operations

[Jeffrey R. Carter]

Maciej Sobczak wrote:

> My confusion is that Op_B is private in P2. X is declared in P2 as well. 
> In the above call, I'd expect P2.Op_B to be called (which is actually 
> the case), but since everything is known statically, then I'd expect as 
> well to get compile-time error due to the fact that P2.Op_B is private.

The important point is in 20.f: "The overriding declaration for P2.Op_B is not 
visible in Main, so the name in the call actually denotes the implicit 
declaration of Op_B inherited from T1."

Note that there is an implicit declaration of Op_B in P2 at the point of the 
type extension.

Also note that X is not declared in P2; it is declared in Main.

-- 
Jeff Carter
"My brain hurts!"
Monty Python's Flying Circus
21

Re: Dispatching operations

[Maciej Sobczak]

Jeffrey R. Carter wrote:

>> My confusion is that Op_B is private in P2. X is declared in P2 as 
>> well. In the above call, I'd expect P2.Op_B to be called (which is 
>> actually the case), but since everything is known statically, then I'd 
>> expect as well to get compile-time error due to the fact that P2.Op_B 
>> is private.
> 
> The important point is in 20.f: "The overriding declaration for P2.Op_B 
> is not visible in Main, so the name in the call actually denotes the 
> implicit declaration of Op_B inherited from T1."
> 
> Note that there is an implicit declaration of Op_B in P2 at the point of 
> the type extension.
> 
> Also note that X is not declared in P2; it is declared in Main.

Thanks, this clears thing a bit.

The question remains, though: how can I get compile error when calling 
private P2.Op_B?
If it's not possible, what's the point in making it private?

When I make this operation (P2.Op_B) public, the it hides the one 
inherited from P1.T1 and it is no longer possible to call P2.Op_B(Arg => 
X), because the named association of parameter is wrong. This means that 
by "promoting" something from private to public (!) in the given package 
I can break the existing client of that package.
This is a strange concept to me.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Dispatching operations

[Jeffrey R. Carter]

Maciej Sobczak wrote:

> The question remains, though: how can I get compile error when calling 
> private P2.Op_B?
> If it's not possible, what's the point in making it private?

P2.Op_B is a public operation, inherited as part of the type extension. The Op_B 
in the private part is an overriding of the inherited operation. Thus, the 
client has visible an operation named Op_B with a parameter named Arg. Where the 
private part of the package is visible, the same operation has a parameter named 
Param.

The reason it's in the private part in this example is to show that an 
overriding can be private, but the client still calls the overriding by calling 
the inherited operation. It also shows that an overriding can change parameter 
names.

Normally one would put such an overriding in the private part to allow the 
client to continue to rely on the same parameter names and defaults as the rest 
of the type hierarchy, while allowing the package implementation to use names or 
defaults that are more appropriate to the implementation.

> When I make this operation (P2.Op_B) public, the it hides the one 
> inherited from P1.T1 and it is no longer possible to call P2.Op_B(Arg => 
> X), because the named association of parameter is wrong. This means that 
> by "promoting" something from private to public (!) in the given package 
> I can break the existing client of that package.
> This is a strange concept to me.

Why? If you change the visible part of the package spec, the clients should 
expect to have to change, too. That's why the compiler will force recompilation 
of the clients.

-- 
Jeff Carter
"To Err is human, to really screw up, you need C++!"
St�phane Richard
63