Re: package dependence question

["Robert I. Eachus" <rieachus@earthlink.net>]

"Antonio Durán Domínguez" wrote:
 
> There are different forms for aproaching to the solution. I think the most
> flexible is the object oriented way so that the nodes of the tree are
> classes (tagged types) that inherit from a common class. This provides
> flexibility (new classes are easily added) and separates the tree handling > from tree-node handling.

  I think that an even better approach is to use mix-ins.  You create a
tree
type and a node classe in a library package. Then in a nested or child
generic package, you create a specific node type that contains an object
of
the generic formal type:

  generic
    type Content is {tagged} {limited} private;
   {Node_Name: in String;}
  package Tree.Specific_Node is

    type New_Node is new Tree.Node with private;

    generic
      type Data is private;
      with procedure Action(Object: in out New_Node; D: in Data);
    procedure Update(Object: in out New_Node; D: in Data);
   
  private
    -- overridings go here. 
  end Tree.Specific_Node;

  Part of the magic of doing this right is that most of the operations
on a node need to be written once, in the proper place--either as an
operation of the Node type or of the Content type.  The one exception is
that operations that change the value of the contents of the node
require the addition of a generic instance of Update.  If different node
types have lots of different update operations, this can begin to get
painful, especially if you have to create new record types to collect
parameters in.