>Phil Hudson <phil.hudson at iname.com> wrote:
>> >It could raise an Exception...but the program
>> >will break anyway! 
>> 
>> Yes. This is a good thing. No, really. :-)
>
>I think you are missing the point.  If the object is of the wrong type,
>then eventually some part of the code will remove the object from the
>collection and try to use it... and fail.
>
>The advantages you need to push are:
>
>	1. It finds the error sooner, at the time the object is added to the
>collection.
>
>	2. It finds the error even if the particular object is in fact never
>pulled back out of the collection.

Well said. That is the point.

>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).

>Also, there's a downside to extra checks in the code: it means more
>code, and more code means that changes are harder to make.

Again true, and this time more persuasive. But there is an upside too:
assertions make your program self-documenting with regard to its expected
state and behavior, which makes the code more comprehensible.

>> 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.
>
>You can certainly well disable Object>>assert: if you care to, and have
>it be a noop.

I would argue that this is not true. There exists a number of
Object>>assert: sends in the standard distribution image. On a quick
analysis it looks like none of them would break, but in principle, this
is not a decision that you or I can make, since it affects someone else's
code in ways that (again in principle) we can't be sure of. Hence my
Assert package, which works around the problem using indirection; my
assertions are all calls to Assert assert: rather than self assert: