I know that in some languages this matters, and in others it doesn't. E.g., in C if you return a value, the temporary must always be stored when the function is called, but in other languages it can be ignored, and in some languages if you don't intentionally return a value, the system will automatically create a value (usually nil) to return for you.
Eiffel make a big deal about separating Commands from Queries, with very strict rules about which kinds of routines can do what kind of things.
Presumably Squeak (and Smalltalk) is flexible here...but I haven't seen it documented anywhere. (Also, can anyone recommend a good tutorial that isn't graphics based? What I want to do right now is really more text oriented.) I got the two Mark Guzdial books, but that doesn't really cover much in any depth.
Charles,
Im a beginner myself, but i think i know the answer to this one... ;)
As far as i know every method returns a value. If you do not explicitly return a value ^self is returned.
BTW i love this list, and ive learned very much already from it. Keep up the good work all!
- Jeroen
"Charles D Hixson" charleshixsn@earthlink.net wrote in message news:446025AD.1010407@earthlink.net...
I know that in some languages this matters, and in others it doesn't. E.g., in C if you return a value, the temporary must always be stored when the function is called, but in other languages it can be ignored, and in some languages if you don't intentionally return a value, the system will automatically create a value (usually nil) to return for you.
Eiffel make a big deal about separating Commands from Queries, with very strict rules about which kinds of routines can do what kind of things.
Presumably Squeak (and Smalltalk) is flexible here...but I haven't seen it documented anywhere. (Also, can anyone recommend a good tutorial that isn't graphics based? What I want to do right now is really more text oriented.) I got the two Mark Guzdial books, but that doesn't really cover much in any depth.
The rule is, if you don't return a value, then self is returned. There's no such thing as a void message like in C++ or Java.
Tell me what you want to do and I'll see if I can scare up some examples.
On May 8, 2006, at 10:16 PM, Charles D Hixson wrote:
I know that in some languages this matters, and in others it doesn't. E.g., in C if you return a value, the temporary must always be stored when the function is called, but in other languages it can be ignored, and in some languages if you don't intentionally return a value, the system will automatically create a value (usually nil) to return for you.
Eiffel make a big deal about separating Commands from Queries, with very strict rules about which kinds of routines can do what kind of things.
Presumably Squeak (and Smalltalk) is flexible here...but I haven't seen it documented anywhere. (Also, can anyone recommend a good tutorial that isn't graphics based? What I want to do right now is really more text oriented.) I got the two Mark Guzdial books, but that doesn't really cover much in any depth.
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Todd Blanchard wrote:
The rule is, if you don't return a value, then self is returned. There's no such thing as a void message like in C++ or Java.
Tell me what you want to do and I'll see if I can scare up some examples.
On May 8, 2006, at 10:16 PM, Charles D Hixson wrote:
I know that in some languages this matters, and in others it doesn't. ...
...
Returning self is fine. I just wanted to know what would happen, so I could do things properly. (Actually, right not the methods would execute Object shouldBeImplemented, so they probably won't really return anything...but I was trying to plan for the future.) Thanks.
Charles,
Todd Blanchard wrote:
The rule is, if you don't return a value, then self is returned. There's no such thing as a void message like in C++ or Java.
Tell me what you want to do and I'll see if I can scare up some examples.
On May 8, 2006, at 10:16 PM, Charles D Hixson wrote:
I know that in some languages this matters, and in others it doesn't. ...
...
What Todd meant to say was: if you don't *explicitly* return a value with a '^' statement, the receiver (self) is returned. Basically, all message-sending return some values.
Returning self is fine. I just wanted to know what would happen, so I could do things properly. (Actually, right not the methods would execute Object shouldBeImplemented, so they probably won't really return anything...but I was trying to plan for the future.)
I don't know if the following is relevant what you do, but here is a little fun fact.
Almost all errors and explicit runtime exceptions like #shouldNotImplemented are decorated break points. If you push the "Proceed" button in the pink window called notifier, the execution continues. Since Object>>shouldBeImplemented is implemented as: --------- shouldBeImplemented "Announce that this message should be implemented"
self error: 'This message should be implemented' --------- without any explicit return, the receiver is returned and the execution continues. Try an expression like following, evaluate the expression and "proceed".
---------- Transcript show: (3 shouldBeImplemented + 4) printString. ----------
-- Yoshiki
Yoshiki Ohshima wrote:
Charles,
Todd Blanchard wrote:
The rule is, if you don't return a value, then self is returned. There's no such thing as a void message like in C++ or Java.
Tell me what you want to do and I'll see if I can scare up some examples.
On May 8, 2006, at 10:16 PM, Charles D Hixson wrote:
I know that in some languages this matters, and in others it doesn't. ...
...
What Todd meant to say was: if you don't *explicitly* return a value with a '^' statement, the receiver (self) is returned. Basically, all message-sending return some values.
Returning self is fine. I just wanted to know what would happen, so I could do things properly. (Actually, right not the methods would execute Object shouldBeImplemented, so they probably won't really return anything...but I was trying to plan for the future.)
I don't know if the following is relevant what you do, but here is a little fun fact.
Almost all errors and explicit runtime exceptions like #shouldNotImplemented are decorated break points. If you push the "Proceed" button in the pink window called notifier, the execution continues. Since Object>>shouldBeImplemented is implemented as:
shouldBeImplemented "Announce that this message should be implemented"
self error: 'This message should be implemented'
without any explicit return, the receiver is returned and the execution continues. Try an expression like following, evaluate the expression and "proceed".
Transcript show: (3 shouldBeImplemented + 4) printString.
-- Yoshiki
Good. That is exactly the way I would want it to have been designed, now that I think about it.
Am 09.05.2006 um 07:16 schrieb Charles D Hixson:
I know that in some languages this matters, and in others it doesn't. E.g., in C if you return a value, the temporary must always be stored when the function is called, but in other languages it can be ignored, and in some languages if you don't intentionally return a value, the system will automatically create a value (usually nil) to return for you.
Eiffel make a big deal about separating Commands from Queries, with very strict rules about which kinds of routines can do what kind of things.
Presumably Squeak (and Smalltalk) is flexible here...but I haven't seen it documented anywhere.
All you ever do in Smalltalk is send messages to objects, and maybe assign the returned object to a variable. There aren't even control statements (you can look up the ifTrue: method in the browser). When you dig deeper into that you'll discover the beauty of this simple approach :)
Since simplicity is paramount, we do not distinguish between methods that return something or methods that do not. This also would imply that the sending object knows in advance whether the particular message you send will return something or not.
This weak coupling of sender and receiver (sometimes called late binding) also is essential. You can send any message to any object, but it's always the receiver who chooses how to respond to the message. Indeed, even the terminology reflects that - we strongly distinguish between messages and methods, you cannot "call a method", you can only "send a message" which in turn "activates a method".
To return to the return value (pun intended), the *sender* of a message of course knows whether it will use the object returned. That's why the compiler issues slightly different bytecodes in the sending method, but that's mostly for balancing the stack, and a bit for performance.
And about separating commands from queries - this still is a good rule of design, but we do not build it into the language. A nice article about how this fits into OO design is "Tell, Don't Ask":
http://www.pragmaticprogrammer.com/ppllc/papers/1998_05.html
- Bert -
From: Charles D Hixson Sent: Tuesday, May 09, 2006 1:16 AM
I know that in some languages this matters, and in others it doesn't.
If a method doesn't explicitly have a return value it will return self, but you should never count on that, small changes to the method will have a tendency to break your code. Especially when someone decides that the method should return something like true or false.
If in your code you really want "self" back from a method you can protect yourself from this problem by adding ; to the end of your method call.
For example:
aFireman putOutFire
may return nothing in which case the following would work since it returns self.
aFireman putOutFire cleanUpMess.
But if someone decides that putOutFire should return #smokeDamage then you would be in trouble. So it's better to write the code
aFireman putOutFire; cleanUpMess. This says send the next message to the receiver object of the previous message and it translates as
aFireman putOutFire. aFireman cleanUpMess.
And if you haven't guessed aFireman putOutFire; cleanUpMess; driveBackToStation. Works too.
Also sometimes what is returned can get in the way and if you really need to return self you should add the following.
aFireman putOutFire; yourself. This way you could guarantee that the right object "self" ends up where it should.
For example
aFireStation medalCandidates add: (aFireman putOutFire; yourself).
This makes sure that "self" is returned and changes to the implementation of putOutFire will not hurt your code.
This is especially useful in collections, since add returns the object that was added and not the collection.
aCollection := aCollection add: aFireman
would set aCollection to aFireman, not what was intended.
But
aCollection := aCollection add: aFireman; yourself.
Returns aCollection with an additional fireman in it.
Hope that helps!
Happy Coding!!
Ron Teitelbaum President / Principal Software Engineer US Medical Record Specialists Ron@USMedRec.com
What is also nice is to explicitly state that a method return self
even thought
foo
blblbl
is returning self
writing
foo blblbl. ^ self
Is a really nice to indicate to our reader that the self is important in that case.
This is why I would like change yourself implementation to do exactly that :)
Stef
beginners@lists.squeakfoundation.org
-
Bert Freudenberg -
Charles D Hixson -
Jeroen van Hilst -
Ron Teitelbaum -
stéphane ducasse -
Todd Blanchard -
Yoshiki Ohshima