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
|