Re: Access idiom

[Gene <gene.ressler@gmail.com>]

On Jan 21, 10:56 pm, Gene <gene.ress...@gmail.com> wrote:
> On Jan 21, 1:15 pm, "Jeffrey R. Carter"
>
> <spam.jrcarter....@acm.nospam.org> wrote:
> > Gene wrote:
>
> > > I'm at an impasse developing a graph data structure.  There are many
> > > node types derived from a "most general" one.  Most of the node types
> > > contain fields that are classwide access to child nodes.  Various
> > > primitive procedures operate on nodes, dispatching on unnamed node
> > > access types.  In many cases, the operations return such an access
> > > child value.  Other "identity" ops just return the dispatching
> > > parameter as classwide access.
>
> > There should be no need for public access types or values in such a data
> > structure. Hiding them should make the package easier to use, easier to
> > implement, and safer.
>
> First, I think the collective wisdom has put me straight. Thanks.
>
> Another, more succinct explanation...  The graph has many node types,
> all with common ancestor.  Edges are pointers--named or anonymous
> access Node_Type'Class; don't care which.  Required is a primitive
> "transform" procedure that dispatches on node type and must return a
> pointer to an _arbitrary node type_ (i.e. again of type access
> Node_Type'Class).  Frequently the transform should just return its
> parameter without modification.  Using primitive functions (which
> would enable return of anonymous access Node_Type'Class) is not good
> due to need for multiple return values.
>
> Jeff, in view of all the above, a named "access all Node_Type'Class"
> type seems necessary for the return values.
>
> I failed earlier because the out parameter wouldn't convert
> automatically from named to unnamed access, and I didn't realize type
> conversion would work on L-values.
>
> Further comments very welcome if there is a better way.  Again,
> thanks.
>
> This compiles and dispatches as expected:
>
> ---- hoo.ads
> package Hoo is
>
>    type Node_Type is abstract tagged null record;
>    type Node_Ptr_Type is access all Node_Type'Class;
>    procedure XForm(P : access Node_Type;
>                    Rtn : out Node_Ptr_Type) is abstract;
>
>    type Binary_Type is new Node_Type with record
>       Left, Right : access Node_Type'Class;
>    end record;
>
>    overriding
>    procedure XForm(P : access Binary_Type;
>                    Rtn : out Node_Ptr_Type);
> end Hoo;
>
> ---- hoo.adb
> package body Hoo is
>
>    overriding
>    procedure XForm
>      (P : access Binary_Type;
>       Rtn : out Node_Ptr_Type)
>    is
>    begin
>       Rtn := Node_Ptr_Type(P);
>    end XForm;
>
> end Hoo;
>
> ---- foo.adb
> procedure Foo is
>    P : access Binary_Type;
> begin
>    P := new Binary_Type;
>    Xform(P.Left, Node_Ptr_Type(P.Left));
> end Foo;

I guess this classifies as a "duh..."  Declaring graph edges as
Node_Ptr_Type instead of access Node_Type'Class eliminates need for
type conversion at call site...  So now the 2nd last line above is
just

Xform(P.Left, P.Left);

Entlich ist es ganz sauber!  Fascinating that changing all the
declaration _and_ implementation code from

Xform(P : in Node_type; Rtn : out Node_Ptr_type);

to

Xform(P : access Node_Type; Rtn : out Node_Ptr_type);

was possible with only find-and-replace edits (including deletions of
many .all's) ... good evidence of the orthogonality and consistency of
Ada syntax.

Thanks for remarks that access params incur a performance hit.  In
this app, clean, simple syntax is far more important than performance.

All the best,
Gene