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

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

On Fri, 4 May 2012 20:48:53 +0200, Felix Krause wrote:

> 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.

I don't like re-dispatch, it is a design bug to me.

>> 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.

That depends on what you mean. Classes (types constituting them) stretch
across packages, as types don't live in the vacuum.

Ada separates types and visibility. Comparing to other languages it is a
great advantage. I understand that you see it differently, but that is
because you haven't yet accustomed to the Ada's model.

Note that Ada has another (inferior) model as well. It can be seen in Ada
protected and task types. They are mess. It was a mistake.

> 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.

Only if you want to access private, i.e. implementation-dependent, stuff.
Note that when a package depends on the implementation details of another
package, this constitutes a tight coupling. Ada requires the programmer to
manifest this design decision in the form of a parent-child package
relation. This IMO is a good thing. You cannot access the implementation
details if you don't state your intention making it visible for the reader.
Note also that this decision is all on the child's side. In the competing
model, any derived type always get access, so the decision is on the parent
type side. This is a bad design because it forces the programmer to make
his choice early and, maybe, it does a wrong person.

> I for myself would rather want to 
> place my code in the package hierarchy of my application.

That is not a problem, you can rename packages.

>  * 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;

You use a generic child:

generic
package P.Q is
   type B is new A with private;
private
   ... -- You have visibility of P's private here
end P.Q;

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