[Newbies] 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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Re: [Newbies] Where is the setter for self?
On 01.06.2012, at 17:42, Chris Cunnington wrote: > 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, 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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Re: [Newbies] Where is the setter for self?
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:
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
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners
___
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Re: [Newbies] Where is the setter for self?
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
wrote:
> 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:
>>
>> 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
>> Beginners@lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
>
> ___
> Beginners mailing list
> Beginners@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
___
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Re: [Newbies] Where is the setter for self?
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
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Re: [Newbies] Where is the setter for self?
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
wrote:
> 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
> Beginners@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
___
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Re: [Newbies] Where is the setter for self?
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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Re: [Newbies] Where is the setter for self?
On 01.06.2012, at 22:26, Chris Cunnington wrote: > 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. :) 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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Re: [Newbies] Where is the setter for self?
Chris Cunnington wrote:
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
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
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Re: [Newbies] Where is the setter for self?
That's a good way to break it into more manageable pieces. Thanks! Chris 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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners ___ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
