Generics

Colin Putney cputney at wiresong.ca
Sat Oct 4 18:08:37 UTC 2003


On Saturday, October 4, 2003, at 02:35 AM, Phil Hudson wrote:

>> IMHO, it's not worth it.  My intuition--which could well be wrong--is
>> that type errors are blatant.  They tend to cause the house to burn 
>> down
>> all by themselves, without any help.  You don't need to look for type
>> errors in particular, because the general correctness tests will pick 
>> up
>> type errors along the way.  If you ensure that 2+3 is 5, there is no
>> point in having a second check that you got an integer back.
>
> This is true but not a persuasive argument against using assertions. It
> must be better to catch any error you can as early as you can, and to
> know that by using a general-purpose approach you will catch *all*
> occurrences of a *kind* of error early, not just specific occurrences 
> you
> happen to be looking at, testing or running - none can be hidden or
> propagated. (At least, that's the theory).

I think the key phrase in Daniel's response is "it's not worth it."

Eliminating whole classes of errors is certainly a worthy goal, but 
that kind of thing never comes without a price. So your assertion that 
"it must be better" to catch those errors  in a general way is 
incorrect. It's a tradeoff between the cost of generality and the cost 
of the errors. The differences between C++, Java and Smalltalk, for 
example, can be seen as different choices in this regard - GC vs memory 
management errors and static typing vs type errors.

(As a side note, I'm also having a little trouble with the word "early" 
here. In a language like C++ or Java, it's clear - compile time is 
earlier than run time. In Smalltalk there's no such distinction. So 
it's not clear that a general purpose approach would catch the error 
any "earlier" than an ad hoc approach. Yes, catching the error when an 
object is put into a collection is earlier than when it's taken out, 
but is it earlier enough to make a difference? That depends on how the 
collection and the object are used. It might be, but my intuition says 
not very often.)

Anyway, I agree with Daniel that it's not worth it. In Smalltalk, type 
errors are so easy to find and so easy to fix that general mechanisms 
to prevent them end up being to restrictive to be worthwhile. Static 
typing is only the most extreme example; I don't think runtime 
type-checking mechanisms like TypeSafeBag are worth it either.

Wrapping a collection in a type-checking proxy adds complexity to the 
program. Sure, it's not hard to read the code for TypeSafeBag and 
understand what it does, but to really gain the benefits of type safety 
you can't be type safe in only one place. You'd need type-checking 
bottlenecks all over the place. That would make the code hard to 
understand and hard to maintain. It would end up being a kind of poor 
man's static typing, but *without* tool support. Yuck.

I find that in practice, type errors aren't a big problem. They do 
occur, but they're almost always trivial to find and fix.

Colin



More information about the Squeak-dev mailing list