[Newbies] Where is the setter for self?

Chris Cunnington smalltalktelevision at gmail.com
Fri Jun 1 20:26:15 UTC 2012

On 12-06-01 3:55 PM, Ralph Johnson wrote:
> OK, what do you think the inspector should show on the screen for an
> object?
I wouldn't say it needs to change. I need to understand it better. I'll 
flatter myself and say these were the kinds of questions David Ungar 
asked himself.
>    What do you think it should put for "self"?
Nothing. As a use of visual space it makes good sense to put self beside 
the printString. But as I've been ranting to myself for about an hour 
now: "self is not the printString!" That's true. But a better programmer 
than myself would already know that.
> Would you like some sort of object ID, perhaps its address in memory?
I'm confident that this is the best possible design. A hash or location 
in memory would be worse. All I'm trying to get my head around here is 
the bifurcation between the immutability of self and what it is 
connected to; as opposed to, the arbitrary and flexible nature of the 
printString. Lukas knows this and so he made it work for him in the 
exercise of creating strings that are JavaScript. (And to reference a 
point you made before, Lukas does have Object>>asJavaScript. I find the 
things he does confounding, but I don't want to misrepresent him.)

The shape of the Inspector led me to a fallacy, I think:

self new Control.Slider(null,null)
all inst vars
decoration a SUCreate
canvas nil
options nil
handleId nil
trackId nil

My mistake is looking at self as though it's an inst var, but it's above 
the fold. I thought "Well, it's a pseudo variable ..."

It's clearer to me to have:

printString new Control.Slider(null,null)
all inst vars
decoration a SUCreate
canvas nil
options nil
handleId nil
trackId nil

But that makes no design sense to a person arranging information on a 
screen. Now that I get it, it looks fine. :)
> Smalltalk doesn't have a standard object ID that you can access.  It
> isn't hard to give each object a unique ID for its class, so that the
> objects could print themselves as "Thingee 1" and "Thingee 2".   But
> that is up to the programmer.
> -Ralph Johnson
I've never seen printing and the use of streams in printing too clearly. 
ObjectMemory, the Interpreter are clear objects on the learning 
landscape. ParagraphEditor with its printIt and doIt (which I've heard 
people talk about for years) comes to me as a revelation.


More information about the Beginners mailing list