Re: Type-checking trick

[Benjohn Barnes <b.barnes@...>]

on 25/7/02 5:22 PM, Tom Wrensch at twrensch@uop.edu wrote:

> You type checking solution is clever, but I'm not sure it will solve the
> problem you want to solve. The difference between what you're doing here
> and what C or Java does when it type checks is *when* the type check
> happens. In C and Java a type error is found at compile time, in your
> program it's found at run time.
> 
> The differences is that you have to actually execute a piece of code to
> check if it is passing arguments of the correct type. More importantly,
> you have to check every possible call point to be sure that each place
> that calls the function is passing values of the correct type.
> 
> As a quick example:
> 
> -- This function checks its arguments at run time
> function test(num, tab)
> assert(type(num)=="number")
> assert(type(tab)=="table")
> tab.value = num * 2
> end
> 
> function main(num)
> assert(type(num)=="number")
> local t={}
> test(num, t)  -- This is okay
> if num < 0 then
> test(t, num * -1) -- This is not
> end
> end
> 
> Note that the type error in the function main() will only show up if its
> argument is less than 0. If this is rare, you could go through a lot of
> testing, and still miss that one case. It will, of course, then turn
> around and bite you on the first real deployment.
> 
> Having said that I should point out that I've been involved in quite a few
> Smalltalk development projects, two of which were quite large (100,000+
> lines of code). Smalltalk has the same "problem" in that it does not have
> static type checking. We very rarely found these sorts of type errors to
> be a problem.

I'm glad this subject has come up, as I'd often wondered how big a problem
it would actually be. Static typing enthusiasts will often claim it's a huge
disadvantage of a dynamically typed language. It's great to hear someone
who's used it with a positive opinion about it.

In essence, it's simply the usual debugging problem of exercising all
possible code paths. I'd hazard a guess that it would almost always show up
very quickly during development. I'd also suspect that good design and
practice would help alleviate more insidious problems, just as they do this
algorithmic bugs.

Cheers,
    Benjohn