krause@prlhp1.prl.philips.co.uk (krause) (02/05/90)
Hi,
A quick smalltalk question.
If you code something like:
Fred <- OrderedCollection new
add: 'anItem';
add: 'anOtherItem';
add: 'finalItem'
Fred will NOT be an ordered collection, but a string.
------
coding:
Fred <- OrderedCollection new
add: 'anItem';
add: 'anOtherItem';
add: 'finalItem';
yourself
Will result in Fred becoming an ordered collection. The funny thing is that yourself
is a method that does nothing. I even coded up a dummy method for ordered collection
and used that instead of yourself .... this resulted in Fred being correct.
Code like
Fred <- OrderedCollection new.
Fred add: 'anItem';
add: 'anOtherItem';
add: 'finalItem'
works as I currently expect.
Has anyone any comments or suggestions? Exactly WHAT IS OCCURING?
I have smalltalk version 2.3 running on an Apollo.
David
-----new@udel.edu (Darren New) (02/06/90)
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
@ add: 'anItem';
@ add: 'anOtherItem';
@ add: 'finalItem';
@ yourself
@Will result in Fred becoming an ordered collection.
yourself, not containing a return, defaults to returning self. Thus,
the new OrderedCollection is returned and assigned to Fred.
@ 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!
Darrenschang@netcom.UUCP (Sehyo Chang) (02/07/90)
In article <1045@prlhp1.prl.philips.co.uk> krause@prlhp1.UUCP () writes: >Hi, > >A quick smalltalk question. > >If you code something like: > > Fred <- OrderedCollection new > add: 'anItem'; > add: 'anOtherItem'; > add: 'finalItem' > >Fred will NOT be an ordered collection, but a string. > ------ > >coding: > > Fred <- OrderedCollection new > add: 'anItem'; > add: 'anOtherItem'; > add: 'finalItem'; > yourself > >Will result in Fred becoming an ordered collection. The funny thing is that yourself >is a method that does nothing. I even coded up a dummy method for ordered collection >and used that instead of yourself .... this resulted in Fred being correct. > >Code like > > Fred <- OrderedCollection new. > Fred add: 'anItem'; > add: 'anOtherItem'; > add: 'finalItem' > > >works as I currently expect. > >Has anyone any comments or suggestions? Exactly WHAT IS OCCURING? > >I have smalltalk version 2.3 running on an Apollo. > > The method 'yours' does something. It returns 'sender'. When you have cascading message like "OrderedCollection new; add: 'anItem' ", the result of expression is result of last expression in the cascade message. Thus result will be method "add: 'anItem'". If you browse through class 'OrderedCollection' it will evaluate argument(string in this case) instead of the OrderedCollection. Second example works as you expected because you already assigned collection to the variable and doesn'depended on side effects of evaluation. -- Sehyo Chang schang@netcom.uucp Ascent Logic Corp. (408)943-0630
cs3p+@andrew.cmu.edu (Chris J. Stluka) (02/07/90)
Hi, In Smalltalk V/Mac, you could do this: (Fred := OrderedCollection new) add: 'anItem'; add: 'anOtherItem'; add: 'finalItem'. Try something like that. In this, Fred is assigned to be an OrderedCollection, and the result of the assignment statement is the OrderedCollection. Chris Stluka.
MUHRTH@tubvm.cs.tu-berlin.de (Thomas Muhr) (02/08/90)
In article <1045@prlhp1.prl.philips.co.uk>, krause@prlhp1.prl.philips.co.uk (krause) says: > >Hi, > >A quick smalltalk question. > >If you code something like: > > Fred <- OrderedCollection new > add: 'anItem'; > add: 'anOtherItem'; > add: 'finalItem' > >Fred will NOT be an ordered collection, but a string. > ------ > >coding: > > Fred <- OrderedCollection new > add: 'anItem'; > add: 'anOtherItem'; > add: 'finalItem'; > yourself > >Will result in Fred becoming an ordered collection. The funny thing is that >yourself >is a method that does nothing. I even coded up a dummy method for ordered >collection >and used that instead of yourself .... this resulted in Fred being correct. > >Code like > > Fred <- OrderedCollection new. > Fred add: 'anItem'; > add: 'anOtherItem'; > add: 'finalItem' > > >works as I currently expect. > >Has anyone any comments or suggestions? Exactly WHAT IS OCCURING? > >I have smalltalk version 2.3 running on an Apollo. > The default return-object of every method is the instance which the message is sent to. If you want anything else than the instance you must specify what is to be returned with the caret ^. The semantics of message-returns seems to be a bit nonsystematic in ST, for instance the add: method for OrderedCollections: it returns the object added!. So to come around this, you have to send as the last message in a cascade of messages one which returns the object all the previous messages were sent to. And this last message is 'yourself' - you have noticed that it is of the simple sort - it does nothing except redirecting the pointer to what you want, despite of what previous messages return. It is often used in the creation of panes within an open method. Before you addSubPane to a TopPane, which you have sent messages not returning the TopPane, you better send a 'yourself' as last message to the TopPane: topPane:= (TopPane new model:xxxxx; label:nnnnn;.......;yourself). topPane addSubpane: spspspsp. (I am an eager student of this newsgroup....) So long - Thomas > >David >----- ------- Thomas Muhr, Technical University of Berlin, BITNET: muhrth@db0tui11 Project ATLAS - Computer Based Tools for Qualitative Research "Computers, like every technology, are a vehicle for the transformation of tradition." (WINOGRAD/FLORES)
andrew@computing-maths.cardiff.ac.uk (Andrew Jones) (02/10/90)
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
new@udel.edu (Darren New) (02/13/90)
In article <1151@cf-cm.UUCP> andrew@computing-maths.cardiff.ac.uk (Andrew Jones) writes: >As for making it more flexible, I can't see this. . . . >(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. Speaking from my experience with threaded interpreters (e.g., FORTH), the thing you want to return is the thing you are more likely to have to calculate. (In FORTH, the thing on the top of the stack is the thing you are less likely to calculate, so that it may be passed to another routine.) So in forth, you say BLAH BLECK ! to store BLAH into the variable BLECK. Normally, the right-hand side expression goes left-most so that it is deeper and easier to pass on the stack without SWAPs and ROTs. (Did that make any sense? I thought not. Let me try it using smalltalk...) rememberFrom: xyzzy ^MyCollection add: xyzzy + 2 vs. rememberFrom: xyzzy | t | MyCollection add: (t <- xyzzy + 2). ^t where the + 2 is to represent an arbitrarily complex expression. Anyway, I think this makes my point. However, the power of Smalltalk is sufficiently greater and the libraries are sufficiently larger that the minor inconvenience at coding time is far outweighed by the major inconvenience of not having consistency in the libraries. On the other hand, there is always "yourself" if there is any doubt. I really think at this point it is a matter of taste. -- Darren