From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,FREEMAIL_FROM, INVALID_MSGID,PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,b7dc7082d345b1e1 X-Google-Attributes: gid103376,public From: "Antonio Dur�n Dom�nguez" Subject: RE: package dependence question Date: 2000/05/29 Message-ID: #1/1 X-Deja-AN: 628520754 References: <8gt19i$1cm8@r02n01.cac.psu.edu> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Complaints-To: usenet@teleline.es X-Trace: telenews.teleline.es 959588060 192.101.1.126 (Mon, 29 May 2000 10:14:20 MET DST) Organization: Clientes_Teleline X-MSMail-Priority: Normal NNTP-Posting-Date: Mon, 29 May 2000 10:14:20 MET DST Newsgroups: comp.lang.ada Date: 2000-05-29T00:00:00+00:00 List-Id: 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. Another approach could be using a variant record to hold the node information and a single access type to handle the tree links. This is pretty much Ada 83 style but has the limitation that the types of nodes must be known at compile time and new types of nodes are not easily incorporated to the code. Carl Banks escribi� en el mensaje de noticias 8gt19i$1cm8@r02n01.cac.psu.edu... > Okay, when I program, I like to construct large, dynamic tree > structures. I like my trees to be traversible in any direction, so if > you're sitting on a node, you can access its parent or any of its > branches. > > So let's say that a particular tree has a different type of node at > each level. For example, type A is the root of the tree. Its > branches are of type B. B's branches are of type C, and so on. > > Let's also say that A, B, and C are not really similar (they are only > similar in that they are in the same tree structure, but bear no > internal resemblance to each other). A, B, and C really belong in > separate packages. > > However, packages can't with each other, meaning that types A and B > can't store access types to each other if they are defined in separate > packages. It seems that I have to choose between making the tree > traversible in only one direction, or defining A, B, and C in the same > package. > > The best solution I could come up with myself is to make A, B, and C > child packages of a package such as Node, and declaring the types A, > B, and C (and their access types) in the Node package, while declaring > functions and procedures in the child packages Node.A, Node.B, and > Node.C. This is somewhat messy, as it leaves the fields of type A > open to package Node.B, but at least it isolates the functions and > procedures. > > My question is, is there a better way to define such a doubly- > traversible tree, so that different node types need not be defined in > the same package? > > Thanks. > > > -- > ___\___ ____\___ > \ / .\ \ / .\ > |>< Carl < |>< Banks < > / \_____)_/ / \______)_/