Where are system globals (Smalltalk and SystemOrganization)

Aaron Gray angray at beeb.net
Thu Dec 9 04:37:51 UTC 2004


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





More information about the Squeak-dev mailing list