Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!reading!cf-cm!andrew
From: andrew@computing-maths.cardiff.ac.uk (Andrew Jones)
Newsgroups: comp.lang.smalltalk
Subject: Re: Question on Ordered Collections
Message-ID: <1151@cf-cm.UUCP>
Date: 10 Feb 90 14:36:14 GMT
References: <1045@prlhp1.prl.philips.co.uk> <10271@nigel.udel.EDU>
Reply-To: andrew@computing-maths.cardiff.ac.uk (Andrew Jones)
Distribution: comp.lang.smalltalk
Organization: University of Wales College of Cardiff, Cardiff, WALES, UK.
Lines: 47

In article <10271@nigel.udel.EDU> new@udel.edu (Darren New) writes:
>In article <1045@prlhp1.prl.philips.co.uk> krause@prlhp1.UUCP () writes:
>@    Fred <- OrderedCollection new
>@        add: 'anItem';
>@        add: 'anOtherItem';
>@        add: 'finalItem'
>@Fred will NOT be an ordered collection, but a string.
>
>The value assigned to Fred is the value returned from the final add: message.
>If you examine add:, you will see that it returns its argument, not self.
>
> [ ... ]
>
>@    Fred <- OrderedCollection new.
>@    Fred add: 'anItem';
>@       add: 'anOtherItem';
>@       add: 'finalItem'
>
>Here, you ignore the vale returned from the add: call and get what you
>expect.  I think it is believed that the argument to add: is more often
>needed after adding than the Collection is; hence, add: returns its argument.
>This kind of stuff is often a gotcha and IMHO makes Smalltalk harder
>to master (but of course more flexible).   Happy Hacking!

I agree that this characteristic makes Smalltalk harder to master. When
you send a message like at: to an object you expect a specific result.
When you send a message like add: to an object there doesn't really
seem to be any obvious result (since add: is conceptually a procedure,
not a function). The sensible thing here is surely to be consistent.
The one way of being consistent in all such situations is to
return the object which received the message (which is the default if
no explicit return is coded anyway). Of course, some may disagree ...

As for making it more flexible, I can't see this. All it means is that
in the current version of Smalltalk the easiest way of getting hold of
the OrderedCollection is to assign it to some variable before adding anything
to it; if Smalltalk were modified so that add: returned the receiver, we'd
get hold of the object added by assigning it to a variable before adding it
(or even while adding it:

     ... add: (myVar <- 'hello') ...         ).
In other words, getting hold of both the collection and the thing added
seems to require a similar amount of effort in both cases.

>		  Darren

Andrew