On Oct 16, 2004, at 9:08 PM, Andres Valloud wrote:

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

There's a big difference between a human reader being able to tell the 
relationships and a program being able to tell.  I'm not a fan of 
manifest typing in the usual Java/C++ sense, but I will note that 
essentially every large scale Smalltalk business framework I have ever 
seen or heard about has an extensive metamodel that does exactly what 
Andreas is talking about: it programatically encodes the relationships 
between (a subset of) the classes in the system.  This gets used all 
over the place: generating UI, persistence, searching/indexing, 
integrity constraints, and so on.

The only question I have is whether we need "a" static type system in 
Squeak (by that definition of static type system), or whether we're 
better off with the current situation, which is to have many static 
type systems, all tuned to a particular problem domain.  I'd like to 
think that the first would work - it would save a lot of time and 
effort - but suspect there may be a lot of value to the second.

Avi