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
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 Some
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 behavi
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
differ
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
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 uni
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 thin
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 informatio
