On Sun, Dec 30, 2012 at 9:13 PM, Casey Ransberger
<casey.obrien.r at gmail.com>wrote:

> 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.
>

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).



> 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.)
>
> 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.
>
> On Dec 30, 2012, at 11:39 AM, Yoshiki Ohshima <Yoshiki.Ohshima at acm.org>
> wrote:
>
> > On Sun, Dec 30, 2012 at 7:40 AM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
> >> On 2012-12-27, at 01:32, Sebastian Nozzi <sebnozzi at gmail.com> wrote:
> >>
> >>> Why do ST methods return "self" if nothing is explicitly returned?
> >>
> >>
> >> 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.
> >>
> >> 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.
> >
> > I thought of it (when I wrote the reply) but isn't this really the
> > argument for returning self instead of nil for example?  Any message
> > send pops all arguments including the receiver and pushes the return
> > value so "self" is not on the stack.  Typical byte code sequence for a
> > method that returns self is popping the last result and ends the
> > sequence with "returnSelf"; so it should be equally efficient if such
> > a method endsWIth "returnNil", if such bytecode exists?
> >
> > --
> > -- Yoshiki
> >
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130102/e076fc8a/attachment.htm