<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Dec 30, 2012 at 9:13 PM, Casey Ransberger <span dir="ltr"><<a href="mailto:casey.obrien.r@gmail.com" target="_blank">casey.obrien.r@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Worth pointing out (at least I *think*) there's little real value in returning nil by default, even though it makes a certain amount of visceral sense.<br>
</blockquote><div><br></div><div>turns out in a distributed systems context nil is far cheaper to return; no minting of a proxy for the result. That's a specialized use. But answering nil when there's no result has a safety aspect, i that it guards somewhat against using the return value when its not intended (nil has some protocol).</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Why would I return nil? Maybe as a sentinel value for something (often I prefer nil to zero for that when there's a nil concept and I want a sentinel.)<br>
<br>
Likewise, there's an argument for returning the last value of a method (like we do with blocks presently, and Self does everywhere) across the board, like e.g. Ruby does, but I'd note: Smalltalk's semantics had a lot of time to evolve. The advantages to answering self by default have stood the test of time in this context, I think:) though that certainly doesn't mean we shouldn't continue to ask questions and look for a better idea.<br>
<div class="HOEnZb"><div class="h5"><br>
On Dec 30, 2012, at 11:39 AM, Yoshiki Ohshima <<a href="mailto:Yoshiki.Ohshima@acm.org">Yoshiki.Ohshima@acm.org</a>> wrote:<br>
<br>
> On Sun, Dec 30, 2012 at 7:40 AM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
>> On 2012-12-27, at 01:32, Sebastian Nozzi <<a href="mailto:sebnozzi@gmail.com">sebnozzi@gmail.com</a>> wrote:<br>
>><br>
>>> Why do ST methods return "self" if nothing is explicitly returned?<br>
>><br>
>><br>
>> One very simple reason has not been stated yet: In the Virtual Machine, returning self is simpler and more efficient than returning any other object.<br>
>><br>
>> Smalltalk byte codes implement a stack machine. That means arguments are passed by pushing them onto a stack, rather than putting them into registers. In addition to the arguments as listed in the method signature, a hidden argument is always passed, which is the receiver of the message. So even for unary methods (those without arguments) the receiver is pushed onto the stack, then the method is executed, and the receiver value on the stack is how the method knows "self". By returning "self" if no explicit return statement is given, the VM can just leave the "self" oop on the stack, which saves at least one memory store operation. So from an efficiency and simplicity standpoint, returning "self" is the most elegant thing to do.<br>
><br>
> I thought of it (when I wrote the reply) but isn't this really the<br>
> argument for returning self instead of nil for example? Any message<br>
> send pops all arguments including the receiver and pushes the return<br>
> value so "self" is not on the stack. Typical byte code sequence for a<br>
> method that returns self is popping the last result and ends the<br>
> sequence with "returnSelf"; so it should be equally efficient if such<br>
> a method endsWIth "returnNil", if such bytecode exists?<br>
><br>
> --<br>
> -- Yoshiki<br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>