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.


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.

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.




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




-Lex