No need to get defensive, no one is going to take Smalltalk away from 
you ;)
If a compiler (because that's what it is, whenever it's run) could save 
you some trouble, why not let it?
Simply stating that the problem is the code doesn't really help anyone, 
you could use that as an argument to skip all checks that are already 
in Squeak since the code should be clear enough to do without them.

/Adde

On 2004-10-16, at 21.08, Andres Valloud wrote:

> Hello Andreas,
>
> Friday, October 15, 2004, 5:00:07 PM, you wrote:
>
>>> How would you detect a missing method in a dynamic system? Aside from
>>> the trivial case of there being no method at all of the appropriate 
>>> name
>>> (which Smalltalks detect already) what would you do?
> AR> Well, this is where it gets interesting and why I think we need a
> AR> static type system in Squeak. [...] And suddenly, the whole type
> AR> system becomes a meta-layer for expressing some of the
> AR> relationships between classes throughout the system and that can
> AR> be useful for many different areas.
>
> This is just a solution looking for a problem.
>
> You can certainly find all such silly mistakes by spending time in
> acceptance and unit tests first - which, besides, should be written
> anyway.
>
> If the code isn't clear enough to show the relationships between
> classes throughout the system, the problem is the code.  Why should a
> type system save us the trouble of writing clear code that can be
> shared with others and understood by others?  What happened to the
> idea of a system that can be understood by a single person?
>
> Unfortunately, to me, this sounds very similar to a topic heavily
> discussed previously - that of frameworks being too closely
> intertwined, a.k.a. the Monolithic Image.  Things have not changed.
>
> Could that meta-layer be an existing implementation of the declarative
> approach to Smalltalk?  The ones that come to mind don't need types
> to work.
>
> Smalltalk is powerful because it does NOT have many "features".  It
> should be kept that way.
>
> Andres.
>
>