Generics

Jim Benson jb at speed.net
Sat Oct 4 19:02:43 UTC 2003


Phil,

> Thanks for replying, you've given me some food for thought and a possible
> solution - I hadn't thought of the #isBag approach. However, I think my
> problem is essentially insoluble in Smalltalk. I put this down to the
> lack of either multiple inheritance (yech) or interfaces (yay) in
> Smalltalk. In fact, I would go so far as to make this contentious claim:
> because of this lack, it is not possible to realize the Decorator design
> pattern cleanly, correctly and completely in Smalltalk. That is, you can
> never create a 100% transparently substitutable decorator object in
> Smalltalk. (I notice the illustrative code in the GOF is in C++). I hope
> I'm wrong about this, and that the real problem is just my boundless
> ignorance. Anybody?
>
>

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



More information about the Squeak-dev mailing list