Generics

Phil Hudson phil.hudson at iname.com
Fri Oct 3 17:44:50 UTC 2003


Hi Daniel,

>Hi Phil !
>
>> A Collection can hold zero or more elements, each of any type. Sometimes
>> you nevertheless need to ensure that all elements are of the same type.
>> Say you're collecting Integers and by accident you insert a Symbol
>> representing an integer value, say #'3'. Your code assumes that every
>> element of your collection will respond to #even; therefor, it errors
>> when it iterates over the Symbol element. You can choose to trap this
>> *particular* error in this *particular* case, or you can (should be able
>> to) choose to use a Collection that takes care of ensuring this *general
>> case* of error *cannot* occur.
>
>What does "a Collection that takes care of ensuring this *general case* of
>error *cannot* occur" means for you?

Two words: Automatic prevention.

>What will the collection do when someone try to insert an element of the
>wrong type on it?

Terminate abruptly. Brutally. Just kick the legs out from under. It's
like: your wallpaper is peeling, so you need to set fire to the house and
burn it down quick so you can get the right paste, rebuild the house and
paper the wall again - and this time get it right. Sounds extreme? Not
really - building a house is practically zero-cost in software; missing a
programmer error is not.

Now, I admit that this is an approach that is conditioned by years of
static-compiled and static-typed programming in Java, C, and Pascal. I am
beginning to grasp that the Smalltalk way is to change the app as it
runs, using the debugger and incremental compilation (I have done some
CLOS programming as well, long long ago, so this is not entirely new to
me). I guess the Smalltalk way is to neatly strip off the one piece of
peeling wallpaper and neatly apply a new one without burning down the
house. However, that only fixes the one incident, which has the required
attribute of having been noticed.

>I mean, lets suppose the collection can detect that the object that is being
>added to it is of the wrong type (whatever meaning you give to "type" here).
>What is it expected to do? 

Terminate abruptly.

>It could raise an Exception...but the program
>will break anyway! 

Yes. This is a good thing. No, really. :-)

>Does it make sense to introduce those "type checking" at
>runtime? I don't think so...

Depends what you mean by "make sense". I *want* my app to die when this
*type* of programming error (not just this particular instance) -
introduced by me the programmer - is found. I don't want to go on
propagating or hiding the error or handling it gracefully.

Obviously, there is a class of errors (mainly user errors and runtime
errors) which my program should (must) handle gracefully. But for certain
classes of programmer error, like off-by-one, divide-by-zero, out-of-
bounds, sending messages to uninitialized variables, and manipulating an
object of the wrong type or with the wrong state (where "wrong" can be
definitely known at coding time), it does not "make sense" to let the
program continue; I have made a mistake, I know it (thanks to this
technique), I must correct it.

This is the argument for using assertions. I'm talking about assertions
as in Object>>assert: aBlock, *not* as in TestCase>>assert: aBoolean -
that's something different. Think of it as white-box testing, or
validating my object's implementation. This approach is different and
complementary to SUnit, which is black-box testing, validating my
object's interface. Ideally, my program should not depend on assertions
to function correctly; once they all stop firing, I should be able to
switch them off and have the program run correctly (and faster).
Unfortunately, Object>>assert: does not provide this.

For those who know C and Java assertions and want something like it in
Smalltalk, I have a very small, simple package for working around one of
the limitations of Object>>assert (namely, you can't switch it off)
without breaking existing code.

Regards,
Phil



More information about the Squeak-dev mailing list