Where is the setter for self?

I'm looking at Lukas's Scriptaculous in Seaside 2.6. He has overwritten
#printOn:. A chain of decorations is passed through and at each stage
the resulting string is stored in self. This means the usual process of
self containing "a SomeObject" instance has been supplanted.

This is common. If I print:

'bob' 'bob'

A string has been stored in self. I do not get:

'bob' a ByteString

In a walkback I can see ParagraphEditor>>printIt goes to
Object>>printStringLimitedTo:. And then a LimitedWriteStream becomes
aStream, which is filled with things that somehow go into the pseudo
variable self. Hypothetically, like this:

self setter: aStream

I imagine the process is somewhere in the march from
ParagraphEditor>>printIt to SUObject new.

Where is the setter for self? How is this stream populating this pseudo
variable?

Any help would be greatly appreciated.
Thanks,

Chris
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On 01.06.2012, at 17:42, Chris Cunnington wrote:

It's a bit hard to make out what you are actually asking.

If you implement "printOn:" in any class, then this method determines how instances are printed.

"self" always refers to the receiver object of the currently executing message. It cannot be stored into.

(LimitedWriteStream on: aString) creates a new stream writing to a string. It inherits "on:" from PositionableStream, which puts aString into the stream's "collection" variable.

The "printOn:" method of an object gets a stream passed as its argument. It then sends messages like "nextPut: something" to the stream, which appends something to its collection.

What else would you like to know?

- Bert -

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

http://www.osrcon.ca/image2.png
http://www.osrcon.ca/image1.png

Yea, I'm not asking this very well. And all things Renggli make my head
spin.

In image2, if I inspect the string 'bob' I see self contains a string
called 'bob'. It does not say "a ByteString", which to me means the
usual behaviour has been overtaken by something else. We don't get an
instance; we get only its return value. The instance "a ByteString" was
no longer as important as its return value.

In image1, Lukas has overwritten Object>>printString: in
SUObject>>printString:. And he's using a pattern ("composite with
decorations" or something) to represent the domain of the JavaScript
language in Smalltalk.

If I print "SUSlider new" I don't get "a SUSlider". I get a string of
JavaScript. What is printed out is what is found in self. If I inspect
"SUSlider new" I can see in self the string that will be produced. I can
also see in the decoration instance variable "a SUCreate". With each
decoration in the chain he makes the string in self gets longer. If I
execute that entire piece of code from "SUSlider new" down to
"onChange:" I will get a string of pure JavaScript.

If how I'm asking this is still really confusing, I'll have to sit on it
for a few days. I seem to do my best comprehending when I'm asleep.

Thanks,
Chris





On 12-06-01 12:45 PM, Bert Freudenberg wrote:
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

When you print an object, you get its "print string", i.e. a printable
representation of it.

Suppose you define a new class Thingee.   If you select "Thingee new"
and printIt, you will get "a Thingee".  I think you are asking why
some classes behave differently, how they can print something
different.

The way this works is that the system is sending the "printString"
message to the object, and printing the result.  The "printString"
method sends the "printOn:" message.  The "printOn:" method is defined
in class Object to produce the result you see.  However, it is common
for subclasses to override "printOn:" to do something different.  That
seems to be what happened here.

In none of these cases does anybody ever assign to "self".   When you
send a message to an object, that object is "self" for the duration of
the method.  "self" always means "the object that received the message
that caused this method to be invoked".

My first reaction is that it is bad style to override "printOn:" to
produce Javascript.   The main purpose of printOn: is for debugging.
I would think it would be better to make an "asJavascript" method for
producing Javascript.  But I haven't looked at the code so I can't
really say for sure.

-Ralph Johnson

On Fri, Jun 1, 2012 at 12:18 PM, Chris Cunnington
<[hidden email]> wrote: _______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On 12-06-01 1:31 PM, Ralph Johnson wrote:
> Suppose you define a new class Thingee.   If you select "Thingee new"
> and printIt, you will get "a Thingee".
>
> "self" always means "the object that received the message
> that caused this method to be invoked".

I'm confused between the way things look and the way things are.

I can see why you'd find it odd for me to say self could have a setter.
self is a link, handled behind the scenes, between the instance in
object memory and a string on the screen. If, when I inspect an
instance, the self category says "a Thingee" or

"new Control.Slider('handle','track',{onChange:function(){new
Ajax.Updater('position',null)},sliderValue:null,range:$R(0,100)})"

seems to be immaterial, because all self is doing is holding a thread
from the screen to the place in object memory.

When a person inspects, the string beside self is the print string.
Print this instance and this is the string you will get.

In the inspector, the self variable sits beside the print string. I
think I've found this confusing:

self  "a Thingie"

whereas, this:

self
printString "a Thingie"

might be more explicit, because all I have to do in my mind is this:

self := "a Thingie"

and I think that's what I was doing. Puting the print string beside the
self pseudo variable is sort of weird to me, as self points to object
memory; whereas, the print string points to the screen. I find it a
strange juxtaposition. As near as I can figure it, that was the source
of my confusion.

Thank you for your help,

Chris



_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

OK, what do you think the inspector should show on the screen for an
object?  What do you think it should put for "self"?

Would you like some sort of object ID, perhaps its address in memory?

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

On Fri, Jun 1, 2012 at 2:09 PM, Chris Cunnington
<[hidden email]> wrote: _______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

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:

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

Thanks,
Chris
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On 01.06.2012, at 22:26, Chris Cunnington <[hidden email]> wrote:

Also: what you are seeing next to all the inst vars is their printString.

> ObjectMemory, the Interpreter are clear objects on the learning landscape.

Except they're not Smalltalk objects at all.

> ParagraphEditor with its printIt and doIt (which I've heard people talk about for years) comes to me as a revelation.

Yes, although I find it a bit limiting that our basic tools still rely so much on a textual representation. As you noted elsewhere, Self did a better job UI-wise to make objects tangible.

- Bert -
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Chris Cunnington wrote:
You may already understand the cascade of message sends, or it may be
confounding your understanding.  That is, if you are incrementally
inspecting from "X := SUSlider new" up to each next semi-colon and
seeing each Inspector pointing at a different object, since "new" is
executed each time.  Just to round out your understanding of self try
"Do It" separately on each the following lines...
x := SUSLider new new Control.Slider(null,null) inspect
x handleId: 'handle'
x trackId: track
x value: position
x range: (0 to: 100)
x onChange: ( SUUpdater new id: 'position' )



_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

That's a good way to break it into more manageable pieces. Thanks!

Chris
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners