So you have to run the code to find that out. And there is no other simple way ?
A more "retrospective" (?) way, or a way to avoid to execute critical code directly is to ask "themselves" (i.e. objects) what invariant they satisfy.
In this case, a line something like:
Smalltalk keys collect: [:i | i class].
would return a set with just one element (Symbol). This means that the keys of Smalltalk are all Symbols.
Thats nice, simple and very nice.
Now, David (Lewis) and my suggestion about inserting "self halt" are going to make sense?
Yes, on the second time round, yes.
Yes, but this is one of the downside of a highly dynamic language. The "type" info helps to understand code. Of course, the info can be supplied in other forms like comments or unit tests so doesn't necessarily have to be part of the code...
Before getting into Smalltalk, I was a stongly typed fan, but now am getting into "lazy typing". On the otherhand I would like some form of assertion mechanism that can disappear at compile time if debugging or type checking is disabled. But to implement such a mechanism properly would be quite alot of work to get right both technically and for good usage. Although a simple starting technology would be possible followed by incremental refinement and this may well allow the problem to be solved in a comprehensive manner.
I was thinking about type specs either being single types or as type domains being lists or patterns of types. Domains could be named and used as type qualifiers that could be either coded as run time checks or disolved out giving no runtime overhead.
Aaron