Does Squeak include a generic node class?

Jerome Garcia Jerome.Garcia at wj.com
Fri Oct 23 00:00:02 UTC 1998


     I think I understand what you are saying but I am not sure. Could you 
     give me a description of what you mean by "parameterized mixin" or 
     provide a URL for a site. It is not a term with which I am familiar.
     
     Jerome
     
     --
     
     Jerome E. Garcia
     jegarcia at adventurousmind.com


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


     
One of the reasons I would not favor a TreeNode abastract class 
is that the thing I want to reuse is the pattern, and possibly 
multiple times within the same class.
     
For instance, to a certain extent this happens whenever I maintain 
several collections of different things within an object.  Having 
a superclass in which only one of these one-to-many relationships 
is covered does not help.
     
That's why I do not bother with a commonly used TreeNode, but instead 
manually do the work that a parameterized mixin could do for me.  I
do the rubberstamping because I currently do not have a facility within 
the system to accomplish the same goal.  Such a facility would have to 
manage more than simply stamping out code- I would want it to do
things in a manner such that good software engineering and reuse 
practices become a natural part of working with the environment.
     
As far as running inheritance ( delegation, actually ) through 
patterns... that would be an interesting project for someone. 
The motivation is based on the observation that many patterns
are used again and again, that there are variations in implementation 
of these patterns, and that quite often I am able to parameterize them 
and stamp them out on a grand scale.  At that point I am not
writing individual methods nor specifying individual instance variables, 
I am saying "put this pattern into that class".  That is a different 
mode of programming, and it will require a different set of tools
to facilitate it.  One aspect of that might be that it would be 
worthwhile to run inheritance and behavior through behavioral patterns 
rather than classes, which accumulate several patterns into one context. 
This leaves the issues of working out how to deal with the inter-pattern 
interactions, and the extent to which individual patterns are decoupled 
from other patterns in a given context.  In that model, classes are 
contexts in which patterns live and interact, and ideally to the greatest 
extent possible the atomic particles of a class would be individual 
patterns, rather than individual methods and instance variables.  Or, in 
another way, the patterns within a class context would be the 
instantiations of pattern "classes".  Something like that... Whether this 
would ultimately be good or not I have no idea.
     
BTW, I am sure that this is a somewhat different connotation for the 
word "pattern" than that used by the Patterns people... the problem 
is that "pattern" is such an appropriate name for what I have in mind, 
but unfortunately it was appropriated decades ago and I don't have
a decent replacement term to use instead.  So keep that in mind...
I don't intend to redefine the term, I just haven't found a better name 
for what I'm after.
     
les
     
     
     
     
     
     





More information about the Squeak-dev mailing list