multiple classes with the same name, namespaces

Trygve Reenskaug trygver at
Sun May 28 12:18:28 UTC 2006

At 19:00 27.05.2006, Michael wrote:

>This brings up a point that has been bouncing around for a while.  While
>Smalltalk sees all things as objects, the one thing that is not currently an
>object is source code.  We store the original string from the user as the
>master copy, and derive objects from that.  This is the source of the whole
>Class name thing, and the need for refactoring them.  If we only kept the
>objects (with things like comments intact) and regenerated the source on
>need this would not be an issue.  It would also allow richer literals and a
>few other things.  It could also support auto-formatting of all source code
>if the user chose to do that.  It would require that variable names and
>comments be retained in the image, but with modern machines that should not
>be a big deal.  Done properly it would also resolve the case where different
>intended classes have the same name, as their references would be different.
>When editing the source the system could either prompt for desired class,
>use the pre-existing reference as a guide, or treat non-unique class names
>differently when generating source.

Hear, hear.

Change the CompiledMethod>>sourcePointers from being indexes into a file to 
becoming a link to a source object. What vistas of powerful new IDEs!. Let 
the "real thing" be the binary class and method objects as seen by the VM. 
Let the programmer see code through an IDE. Carefully isolate the links 
between running programs and their sources. Class names, method source, the 
notion of "system", persistence,.. will all be features of the IDE. Why 
should all parts of an image be programmed the same way?



Trygve Reenskaug      mailto: trygver at
Morgedalsvn. 5A
N-0378 Oslo           Tel: (+47) 22 49 57 27

More information about the Squeak-dev mailing list