Brian Brown <rbb at techgame.net> wrote: 
> Certainly not in the 'strongly-typed language' sense of it. :-)

That's *statically* typed, to be pedantic.  Smalltalk is strongly typed,
but not statically typed.  This matters, because strong typing
definitely makes a big difference while static typing is fiercely
debated.



Phil Hudson <phil.hudson at iname.com> wrote:
> A Collection can hold zero or more elements, each of any type. Sometimes
> you nevertheless need to ensure that all elements are of the same type.

A serious problem is that "types" in Smalltalk can be arbitrarily
complex.  They do not have to conform to a simplistic Java type, and
generally they can be phrased in terms of what other types are.  E.g.,
"This collection holds things that, when sent #xmlForStructure, will
return an object that is valid to be passed to #viewXml: on any of the
objcets in this other collection".  This is an extremely realistic type
constraint for an OO language, but it doesn't fit into any of the static
type systems I'm aware of.  Okayi, that's not a lot :)  but it certainly
doesn't fit:

	1. simply-typed systems like in C
	2. simply-typed plus subclasses-as-subtypes like in Java
	3. universal quantification like in ML

Interfaces in Java might crack it, but then I'll change it to:

	*IF* the elements of this collection implement #xmlForStructure which
return objects suitable for #viewXml:, *THEN*  the elements of this
other collection mult all implement #viewXml.

Such a conditional type (I dunno what it would be called in type theory)
puts an intense challenge on type theory for OO languages, and certainly
it will blow away all three of the above familes of type systems.



Now, this said, I grant you that many collections have something simple
in them like integers or "subclasses of ParseNode".  There are
exceptions to the usual case, however.


> The problem is exactly the same in Java: Collection elements can be any
> object. What I do in Java is take the Decorator design pattern approach.
> I use type-safe wrappers for each subclass of Collection. Instances I
> create of Set, SortedSet, etc. are each wrapped with TypeSafeSet,
> TypeSafeSortedSet, etc. The wrappers validate each Collection element for
> a type I specify when the wrapper is created. And, usefully, once you are
> sure that all your Collections are type-safe, you can globally switch all
> the wrapper-adder methods to become identity functions, so that the call
> to wrap a Collection simply returns the unmodified, non-type-safe
> Collection. Thus you lose the checking overhead (and the wrapper object
> creation overhead) once you have validated the consistency of all your
> Collection elements.

Don't you get almost the same checking, but at a different place, by
just running your test code and seeing if a cast fails?  Any code that
uses a generic collection in Java must eventually cast the objects back
from Object to something more specific.  If the type safety fails, then
eventually a cast is going to fail if your tests are thorough enough.

This is exactly what Smalltalkers do to ensure "type safety", except to
take it one step further.  If there's a type error, then the collection
doesn't catch it, and the non-existent cast doesn't catch it, but as
soon as you send a message to the object you will get a
does-not-understand error.



-Lex