Help with Textual Representations of an Object

Hi,

Can anyone offer a simple, plain english explanation for textual
representations of an object as I am really banging my head on this
area?

I understand that Smalltalk always sends back a message answer, whether
one is expected/reguired or not. But it is the way descriptions that
differ for the types of answer that is puzzling me!

If I am correct, a textual representation of a string object is the
string object with single quotation marks around the first and last
character and also a number object is returned as a SmallInteger. Do
these only apply if the message expression contains a get method rather
than a set method?

If it is a set message expression, ie hisAccount balance:100, is it the
object istself that is returned as the textual representation, ie 'an
instance of Account balance 200 overLimit 2000 holder 'Fred Jones'?

Or am I talking complete gibberish?!

Help me SmallTalk forum, you are my only help!

thanks in advance
Tony

Tony,

> Help me SmallTalk forum, you are my only help!

Hmmm, I'm not quite sure what you are asking here but I'll run through
some basics to see if it helps (nb: some explanations below are not the
_full_ story).

Textual Representations
=======================

The mantra is "Everything in Smalltalk is an Object"

'abc', 123, 10@20 are all Objects, instances of a specific class.

'abc' is an instance of the String class
123 is an instance of the SmallInteger class
10@20 is an instance of the Point class

Each class knows how to answer a String which represents the Object,
it's textual representation.  Sending the message #displayString to any
object answers a new String object containing the textual representation
for the object receiving the message. So ..

'abc' displayString answers a String object containing the character
sequence "abc".  nb, the quote marks are _not_ part of the String but
are added when it is displayed, to show that it is a String object being
displayed.  So evaluating the following answers 3 as the String's size

'abc' displayString size

10 displayString answers a String containing the two characters "10"

(10@20) displayString answers a Sting containing the 5 characters "10@20"

Always remember though that it is up to the class receiving the
#displayString message to decide what is an appropriate representation
for one of its instances.  You could theoretically override the
#displayString method in SmallInteger to answer a different String so that

10 displayString

could answer the three characters "ten" or even so that

10 displayString

could answer the thee characters "999"



Return Values
=============

The mantra here is "Every method in Smalltalk answers an Object"

Say we have a class Foo and it has a method

add99To: anInteger
        ^99 + anInteger

Evaluating this with

Foo new add99To: 10

would answer an instance of the SmallInteger class with the value 109.
nb the ^ character is the "return" operator and tells the method what is
to be answered.


Changing the method to

add99To: anInteger
        ^(99 + anInteger) displayString

would now answer an instance of the String class containing the three
characters "109"


Now, as every method _must_ return an Object what would happen if there
was no explicit ^ - for example


add99To: anInteger
        (99 + anInteger) displayString

The default action for a method with no explicit return value is to
answer the Object that received the message.  In effect every method
that doesn't have an explicit return could be seen as being coded like

add99To: anInteger
        (99 + anInteger) displayString.
        ^self

I'll stop there in case I have missed the point of your query.  Ask
again if I have and nobody else answers it .....

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Tony wrote:

> Can anyone offer a simple, plain english explanation for textual
> representations of an object as I am really banging my head on this
> area?

One thing may be worth adding to Ian's comments.

I'm guessing that you are in a workspace using <CTRL+D> to execute/evaluate
snippets of code.  If not then the following may be complete nonsense...

If you are in a workspace (or in the "text bit" of an inspector -- which is
just another kind of workspace), and evaluate:

    hisAccount balance:100

then Smalltalk will invoke the #balance: method of whatever object 'hisAccount'
is referring to.  That will do, well, whatever it does, and will -- more likely
than not -- exit without returning an /explicit/ value, which means that it
will default to returning the account object itself.

Now the extra point I wanted to add is that if you evaluate the expression with
<CTRL+D> (which doesn't stand for 'do it' but for 'display it') then the
workspace will not only evaluate the expression but also try to print out the
result.  To do that it sends #displayString to the /result/ of evaluating the
expression, and then prints that in its window.  (Actually, it doesn't use
#displayString but calls the closely related method #printString, but that's a
detail we can ignore for now.)   The end effect is that if you evaluate:

    hisAccount balance:100.

then Smalltalk will execute the code, which will probably answer an Account
object of some kind, and then (as a completely independent step) ask the
resulting object for its textual representation and display /that/ in the
workspace.

If instead of calling a "setter"-style method, you had called a "getter":

    hisAccount balance.

then the method would answer an /explicit/ value, namely the balance
(presumably an Integer or some other kind of Number).  The workspace would
treat that just the same as before, so it would send #printString to the
number, which would ultimately answer some string or other.  And the workspace
would print that out.

So the difference you are seeing between "setter-" and "getter-" style methods
is that getters return an interesting value, whereas setters just return the
original object ("the receiver" as we say).  In both cases the returned object
gets printed out, but because it is a different object, it gets printed
differently ;-)

I hope this helps (if Ian's post hasn't already cleared the matter up); if not
then please do ask again.

    -- chris