Re: OOP in Ada: Alternatives for "protected" scope

[Felix Krause <flyx@isobeef.org>]

On 2012-05-03 21:56:51 +0000, Dmitry A. Kazakov said:
> 
> If Do_Something varies in children they should override it. The reusable
> parts common for all children can be factored out as a private class-wide
> operation.

Compared to my version (with redispatching issues fixed), this 
alternative enforces a weaker contract. It does not enforce the child 
classes to call Do_Prologue and Do_Epilogue when implementing 
Do_Something. While this fixes the problem that I cannot have an 
abstract method in the private part, I think the mix-in solution you 
suggested in your second post is a better way to handle this.

> All children having access to private operations must be declared in
> children packages.
> 
>    package P is
>       type A is abstract tagged private;
>       procedure Do_Something (Object : in out A) is abstract;
>    private
>       ...
>       procedure Do_Prologue  (Object : in out A'Class);
>       procedure Do_Epilogue  (Object : in out A'Class);
>    end P;
> 
>    package P.Q is
>       type B is new A with private;
>       overriding procedure Do_Something (Object : in out B);
>       ...
>    end P.Q;
> 
>    package body P.Q is
>       procedure Do_Something (Object : in out B) is
>       begin
>           Do_Prologue (Object);
>           ... -- Do specific calculations
>           Do_Epilogue (Object);
>       end Do_Something;
>    end P.Q;
> 
>> In languages like Java and C#, there is a "protected" scope to cope
>> with this situation.
> 
> This is exactly what Ada's private is. The correspondence goes as follows:
> 
> "Public" <-> Ada' public operation
> "Protected" <-> Ada's private operation
> "Private" <-> An operation defined in the package body

So, to be able to use these visibility scopes, the class hierarchy must 
follow the layout of the package hierarchy. I think this is a 
disadvantage for some reasons:

 * Given the scenario that you use an Ada software library containing 
tagged types, you have to subclass these types in child-packages within 
the package layout of the library. I for myself would rather want to 
place my code in the package hierarchy of my application.

 * It doesn't work with generics:

generic
   -- ...
package P is
   type A is tagged private;
   -- …
end P;

package Q is
   package P_Instance is new P (...);

   type B is new P_Instance.A with private;
end P.Q.R;

Any non-generic tagged type derived from an instance of a generic 
parent type cannot access that type's "protected" methods - as all 
child packages of a generic package also must be generic.