Re: Polymorphism

[slos <new.stephane.los@gmail.com>]

Le jeudi 7 mai 2015 21:09:33 UTC+2, Randy Brukardt a écrit :
> "Dmitry A. Kazakov"  wrote in message 
> news:...
> ...
> > I don't know why it is not allowed.
> 
> It *is* allowed. The problem in the OPs case is that the routine was 
> abstract. Abstract routines must be overridden, but if it is private a 
> client can't know that. Moreover, a client *cannot* override a private 
> operation, so there could be no client in that case. Thus the original 
> declaration is illegal.
> 
> As Simon pointed out, if the operation is concrete, it is fine to put it 
> there. Then all clients that need to override it have to be child packages. 
> Claw uses this extensively.
> 
> > Moreover, it probably would make sense
> > to move all declarations of overriding into private
> 
> This is my coding standard. I only put new stuff into the visible part.
> 
> > or even further into the package body
> 
> That's not allowed as the tag has to be known when the type is frozen (that 
> is, at the end of the specification). Of course, it would be possible to 
> have a different set of rules where the tag isn't known at that point, but 
> that's not the Ada design.
> 
> > because the fact of overriding is mere an implementation
> > detail, since the primitive subroutine is there anyway no matter what.
> 
> Correct; that's why I put them into the private part.
> 
>                                Randy.

Thank you Randy for your detailed information.

I have corrected my code according to the suggestions found here but I still think that there is maybe something to improve here.

If I remember correctly, I should have verified before posting but it's already late, in C++ one can have protected members which can be used by friends.
I can't see in Ada such thing like protected stuff and friends. Maybe there is ?

Indeed I was looking for something like that.

The client of my root class do not need to have access to those helping methods that have to be implemented by the derived ones.

I am quite happy with the child package solution exposed here by Simon but then that has disturbed my packages hierarchy... ;-)

I had grouped my derived classes by field bus technology, one package for PROFIBUS, another for EtherCAT and so on.

Since the root class, implementing an acyclic request, is independent on the field bus technology, I had had a "with" clause to my derived requests and it was working fine, excepted that my abstract methods had to be public.

So it ends up with two related hierarchies, one descending from the root acyclic request and the derived requests grouped by technology, and another hierarchy holding types, constants, etc... that can be useful also for other stuff like status, indications...

But again, I am fine with that solution if there is no smarter way.

BR,
Stéphane
http://slo-ist.fr/ada4autom