There's a book called 'The Design Patterns Smalltalk Companion" by
Alpert, Brown and Woolf (ISBN 0-201-18462-1) that devotes a chapter to
your Decorator pattern pp 161-177. The book is interesting in a couple
of regards, basically it 'translates' all of the design patterns into
Smalltalk. My favorite bits have to do with the fact that a lot of the
"patterns" are part of  the language Smalltalk itself, and therefore
aren't something that need to be formalized as they are in other
languages/books. You'll notice that the book is much smaller than the
gang of four book. Personally I'm not a patterns type of guy, but I
can see how others might find it useful.
Of course, I view your whole type "problem" a little differently than
the curly brace world. You see, I found out a long time ago that I'm
not a very good compiler; it seems that machines are much better at it
than I am. The time that the curly brace crowd spends statically
typing (and even more entertaining, the invariable circumvention of
static typing) is time that I would rather spend writing programs that
actually do something.
Personally, I think it's ironic that people write programs called
compilers that force users to 'pre-compile' languages before the
compilers actually work. As an example, ask a ten year old which one
of these are not some sort of numbers:
 7   6.3  4/5
Why should I have to (or want to) tell my machine what's obvious at a
glance? At the same time, it's easy to understand:
 7 + 6.3 + 4/5
[ In Squeak the correct syntax is:
      7 + 6.3 + (4/5)
because of operator parsing precedence, but it's still pretty close and
illustrates the idea.
]
You'll point out, "That's great, but what happens if the program passed
something invalid? E.g"
 7 + 6.3 + 'badger'
It's obviously an error. That hopefully would never happen in curly
brace land. You're right there. The question really comes down to what
is the cost of catching this error, and where do you catch it? To me
it's not a compile time error, it's a run time error. This should be
dealt with at run time with something like an exception or being
thrown out to an interactive debugger. I'll point out that the number
of times that I've actually have seen something like this happen in
the last five years of daily use is extremely small. When it did
happen, it pointed to much deeper flaws in the program that probably
could not have been solved by static typing. Problems like those
usually means something is really messed up; related to program logic
errors/stupidity, not semantic problems.
The reason that this  is a disaster in curly brace land is the it
crashes the program. That doesn't seem like very robust behaviour,
though I guess you could make the argument that the program isn't
correct and needs to terminate. That's a hard decision to live with,
because there are very few 'correct' programs. I seem to recall that
folks got pretty excited about the infamous blue screen of death, and
are less excited now that Windoze just reboots itself in such
circumstances instead. Certainly in an interpreted environment it's
unacceptable to just have the program die.
To me it's not that static typing is bad per se, it's just that it's a
complete waste of time. As soon as a language provides a mechanism for
circu mventing the type mechanism, like type casting, you've
essentially castrated the entire mechanism of static typing. It's the
camels nose under the tent flap problem.
The next argument that comes up is that the only way to really make
sure that programs are 'correct' is by rigorous tests. In Squeakland
you'll hear a lot about that, usually referred to as 'SUnit'. It seems
like a more reasonable place to try to catch a party gone out of
bounds. Of course, I'm not a test guy either ...
Jim Benson