"Pattern Hatching"

Daniel Vainsencher danielv at netvision.net.il
Wed Nov 27 21:15:02 UTC 2002


Well, I once bult a parser in T-Gen (TGen generates a LRParser subclass
with its own tailored state machine initialization method). It was sure
useful to be able to generate and test and regenerate them without
having to rewrite or refilein the auxiliary methods I wanted it to call.

So GG was very useful (actually, I did this before reading the pattern,
so I probably used a suboptimal variation), considering I didn't
particularly want to patch TGen to fit what I wanted to do.

I conclude GG does have it's uses, even if they seem contrived if you
assume you're designing the whole thing. 

This is more than can be said for some other patterns, of course. And
nevermind the patterns that vary from being a huge, brittle edifice in
C++ to being 10 lines spread around in Smalltalk, like the FileList
registry.

Daniel

"Richard A. O'Keefe" <ok at cs.otago.ac.nz> wrote:
> 
> I've just been reading the book "Pattern Hatching: Design Patterns Applied"
> by John Vlissides, Addison-Wesley 1998, ISBN 0-201-43293-5.
> 
> I have come away from this with two overwhelming impressions:
> 
> (1) Here is a better than competent OO programmer,
>     and C++ is fighting him every inch of the way.
> 
>     Example after example is basically "how do I design-hack a way
>     around such-and-such a limitation of C++."
> 
>     I've always been fairly positive about patterns, and I've taught
>     them to students.  This book, by one of the GoF, made me wonder.
>     The examples strike me as Heath Robinson-ish; is this because of
>     pattern-think, or is it because of C++?
> 
>     It would be really illuminating to see some of his examples
>     revisited by a better than competent Smalltalker, because I
>     think you'd end up with a completely different set of patterns
>     being applied, or the patterns would look different.
> 
> (2) One of the chapters describes the "GENERATION GAP" pattern.
>     The example is a visual interface builder, where you draw your
>     interface and the tool then generates code.  "Normally, you
>     can't create a finished, nontrivial application automatically
>     with one of these tools; you have to implement some functionality
>     the old-fashioned way, by hand in a programming language."
>     So GENERATION GAP helps you by doubling the number of classes.
>     (Er, really.)
> 
>     But WHY do you have to develop part of the interface in one
>     environment (the interface builder) and the rest in another
>     environment?  Why shouldn't "what to do when you are pressed"
>     be something you can plug in *and test* in the interface builder?
> 
>     The answer appears to be "because the interface builder is
>     generating C++" (see point 1 above) "and can't itself run the
>     code it generates".
> 
>     POOF!  An entire pattern disappears up its own fundament if your
>     environment can represent code as data and can run dynamically
>     generated code.
> 
>     I just wish I understood Morphic better.
> 
> Smalltalk:  back to the future????



More information about the Squeak-dev mailing list