Re: Dispatching operations

["Jeffrey R. Carter" <spam@spam.com>]

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