Please forgive my ignorance, without saying they are absent, I do not see the virtues of this "implicit return" earlier in the method. The argument as put here "feels" to me much like those made by the pro-Goto camp (this is not intended as pejorative) during the debates of the 70's in imperative languages.
Do these really make things clearer in any meaningful way?
-----Original Message----- From: MIME :dway@mat.net > Sent: Monday, September 27, 1999 12:09 PM To: squeak@cs.uiuc.edu Subject: RE: [ENH] Empty return expression
On Mon, 27 Sep 1999, Jarvis, Robert P. wrote:
I don't like this because IMO it obfuscates what's going on > without adding
value. On the contrary, I'd say it's more clear as to the intention of the
return, which does add value.
Basically, it says that you want to exit the method at a > certain point,
and that there is no return value to be used.
It's the equivalent of an implicit return, except earlier in > the method.
Kent Beck and others recommend using implicit returns when > the method is not intending to return anything, because it makes the intention more clear (and I agree). (In other words, with an implicit return, the calling method should not use the returned value.)
So, this seems like a good equivalent of an implicit return, > except that
it is done earlier in the method, because you need to break out of the method. Returning "^self" is misleading, because it implies that you might want to specifically return "self" to be used by the > caller. (True, most Smalltalkers recognize "^self" as a generic return, but it's not always that way.)
I have to admit I thought it looked a little funny for a > minute, but it
seems like a good idea. (unless there's some other potential > problem I'm missing)
- Doug Way
EAI/Transom Technologies, Ann Arbor, MI http://www.transom.com dway@mat.net, @eai.com
If you want to answer self in this situation, then type
^self This requires four keystrokes, and it's clear. Besides, > if the method is
going to answer 'nothing returned' shouldn't it answer nil > instead of self?
Bob Jarvis
The Timken Company
-----Original Message-----
From: Bert Freudenberg [SMTP:bert@isgnw.CS.Uni-Magdeburg.De] Sent: Monday, September 27, 1999 4:36 AM To: squeak@cs.uiuc.edu Subject: [ENH] Empty return expression
Parser patch to allow empty returns that indicate > 'nothing returned' like > > foo ifTrue: [self doSomething. ^]
instead of the currently often (mis-)used foo ifTrue: [^self doSomething] as short form of foo ifTrue: [self doSomething. ^self]
Discussion: > > This syntax matches the implicit > return of self at the end of
a method. It makes the "void" return type of a method > explicit, which is good for self-documenting code. It's backwards > compatible. It's a minor change in the parser. So why not?
It's not compatible to other Smalltalks - but then, > the brace constructs
are even more different.
/bert << File: >> > > > > > >
I think these arguments indicate that there is a need to:
1. Separate the concept of answering an object from the concept of terminating execution of a method 2. Not require that a method answer an object at all 3. Allow a method to answer multiple objects
I like the concept using ^ to terminate a method (as a shortcut for "thisContext terminate"), but only if I can also do:
thisContext answer: 1. thisContext answer: 2. ^
....and provided that ^ really does mean stop evaluation of this method without returning *any* object (as opposed to implicitly returning self).
- Stephen
From: "Stephen Pair" spair@advantive.com
thisContext answer: 1. thisContext answer: 2. ^
I really like this! It gently combines the more general symmetric message sends with the shorthand that's useful 99% of the time.
From: Michael Klein Mklein@nts.net [...somewhat against the idea...] Smalltalk chooses a "fixed" point in language desing space that is good for 99+ % of the time. It also gives you all of the powerfull hooks to handle the remaining small amount. (The powerfull hooks are things like Behavior, #doesNotUnderstand:, #become:, thisContext, etc) These are very powerful for building frameworks that allow "ordinary" (99+%) methods to avail themselves of extreme coolness
Yes, the problem with these sorts of extensions is that the language itself (especially the syntax) has to evolve to allow many of these extremely cool features to actually be used.
There was a good mind-bending paper at OOPSLA a decade or so ago,
on how
to add back-tracking to Smalltalk without VM support (using thisContext).
For example, I typed that in a while ago (posted it to the list as well), and found that for something like it to actually be used, it would need better syntactic support. Asynchronous messaging is a (small) step in that direction, and what I like about Doug's idea is that it tweaks the syntax almost imperceptibly to make asynchronous messaging much more natural to express. If we have to express meta-constructed artifacts in meta-languages (outside the base language), they will not be used.
One of the really neat aspects of Smalltalk for moving language forward is that the fundamental abstractions (object, message, message-send) are actually *much more* general than their current implementations ( data-structures, late-bound procedures, procedure invocation with hierarchically structured name matcing) and need only be tweaked ever so slightly to become even more general.
self doStuff. ^ vs. self doStuff. Processor terminateActive.
I certainly don't want a quiet syntax for killing a process! I want to HEAR the BANG of the bullet that kills it!
This is correct in the context of current Smalltalk-80, where a Process is a heavyweight construct and one most programmers simply do not see. However, when doing asynchronous messaging, "process" termination is roughly analogous to method termination and just about as common. I certainly wouldn't want to write "Processor terminateCurrentMethod" at the end of each method!
I just see the fun of debugging a terminating spurious ^. It's like shooting you self in the foot with a silencer. Your
foot just
disappears without a clue.
I also much rather have single exit methods, with the only exit being termination. Can lead to slightly more complex if-nesting, but is usually worth it.
Marcel
squeak-dev@lists.squeakfoundation.org