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
|