I certainly agree that most objects are specialized kinds of nodes. 
     But, sometimes it is important to recognize a treelike relationship 
     among such connected objects and sometimes it is not. In those cases 
     where it is, I feel that there is an advantage to a having a common 
     protocol for obtaining information about the tree and its members and 
     for manipulating the tree. I also think that there is advantage to 
     easily track down and perhaps subclassing implementations of different 
     kinds of trees when solving problems fitting that pattern. Currently, 
     I think this is a name guessing game.
     
     If I create a subclass of the "TreeNode" class, it does not mean that 
     I have to use the "TreeNode>>children" method externally. A method in 
     my subclass with a name which is meaninful in the problem domain can 
     and probably should be my only reference to "TreeNode>>children". All 
     externally referenced methods should be representative of the domain.
     
     The practice of rubber stamping is a time honored approach to 
     development which has its good and bad points. I do it also. However, 
     I do feel that each time you duplicate code you add points of failure 
     to your system that would be avoided by reuse of superclass code. I 
     expect that it also increases the size of the image unnecessarily but 
     as I said I am a Squeak newbie and do not know for certain that this 
     is the case.
     
     I am interested in your comment on changing inheritance so that it 
     does not run up though class but through the patterns out of which 
     classes are constructed. How would this be done?
     
     Actually, I have been wondering whether is is possible to enable 
     Squeak to recognize patterns as new classes are developed and 
     automatically or in cooperation with the developer consolidate code in 
     an effort to avoid duplication.
     
     Jerome
     
     --
     
     Jerome E. Garcia
     jegarcia at adventurousmind.com


______________________________ Reply Separator _________________________________
Subject: Re: Re[2]: Does Squeak include a generic node class?
Author:  Les Tyrrell <tyrrell at canis.uiuc.edu> at INTERNET
Date:    10/22/98 6:26 PM


     
     
>      Although I must classify myself as a Squeak newbie, I do feel that 
>      that this would be the correct approach since Behavior appears to be 
>      just a specialized kind of node.
     
Actually, nearly all objects are specialized kinds of nodes...
        either they have references to other objects, or they do not, 
        either other objects reference them, or not.
     
Although the parent/child pattern is common, I normally do not feel
it is a sufficiently important part of the object in question to warrant 
making that object a subclass of some "TreeNode" class.
     
If there were a reasonable mixin facility, then it would be worthwhile
to have a single implementation that gets used over and over.  But I would 
want it to be better than that, as I would want the mixin to be parameterized 
so that I could change the names of the methods and instance variables to
be more reflective of their use within the context of the new class being 
constructed.
     
As it happens, these days I do use this pattern over and over, and I 
rubber stamp that part of the object from a template that I borrow from 
another class having similar character.  But I do not want to end up 
with methods being the same across totally different classes.
     
So one thing I've considered doing is to change inheritance a bit, so that 
it does not run up through classes, but up through the patterns out of which 
classes are constructed.  I've been wanting to do this for some time, but 
unfortunately I've also been wanting to hook Squeak up to an OO database 
such as Texas, rebuild the entire GUI framework, install a MOP, etc. etc.
     
So basically I'm an idea guy, I guess...
     
( this is a longish way of saying that Object IS a generic node class ).
     
les