Re: subprogram must not be deeper than access type

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 26.09.11 11:45, Natasha Kerensikova wrote:

>> Also, whenever an anonymous type
>> seems to solve a design problem,
>> something might be in bad shape
>> at a higher level.
> 
> Actually I wonder whether there is a design problem at all.

Just a design choice.

In general, I should think that if an author too quickly arrives
at pointers, some C heritage shows. I can really picture the
structs and function pointers, I think :-)

If you have an object of

  type String_Accumulator_Linked_List (Builder : Accumulator_Builder)
     is new String_Accumulator_Stack with private;

then the Builder component is fixed. Fine. Presumably, the operations
of String_Accumulator_Linked_List call Builder as necessary.
So Builder has to be in scope where they do that.

For making Builder visible, an access discriminant pointing
to a function is a possible choice;
there are more ways of making a function visible, not necessarily worse
or better, but they may save some trouble or be of different efficiency,
or clarity.
One is scoping.  Another is instantiation of a suitable generic,
one that declares a simpler String_Accumulator_Linked_List.

At the other end, a factory like Accumulator_Builder might (or might not)
deserve a type of its own. The implementation of the operations of
String_Accumulator_Linked_List would again be able to request
new accumulators from the factory, but this time through operations
of this factory type, adjusted, modified, varied, as needed.  For example,
a task could supply the list with new accumulators from some
foreign pool, and could shape the accumulators as requested.
(The shapes being configured when setting up the factory, or
while it is operating already.)

I'd make a factory object a by-reference type if copying is
a concern, and try to avoid indirection without need.
One way to do away with a pointer to the factory is to
have the core algorithm subprogram take a factory parameter:


   procedure Do_Stuff
     (Factory : Accumulator_Builder; ...)

The invisible difference here is that Accumulator_Builder
would not have to be a pointer.


> Having read the Rationale 2005, I understand now that naming an access
> type is far from being equivalent to text replacement. A slightly less
> readable program text is a small price to pay for the extra safety.

As I understand it, anonymous pointers (a) enable references to nested
subprograms in ways just not possible before their introduction,
and (b) circumvent problems with conversions-to-named and with
implementation techniques. So there wouldn't be an argument about safety,
or is there?