On 3 January 2013 03:56, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> 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).
>

I was also thinking that way before i found that in distributed systems
nil is no longer a singleton:
- suppose i extended Object class with some method, lets say #foo.
- then my user code sends some remote message to some arbitrary object
in a system with such extension,
which evaluates answer to nil
- and then i sending #foo message to result.

now if you substitute remote nil with own nil, you will get DNU, because remote
system nil can understand that message, but local is not.

But in case of return self, this is actually works much better: the
communication layer can check that
message answer is same as a receiver (using identity check), and then,
indeed, it can
do a shortcut and tell the remote sender system that it
can reuse the same proxy (which it used for sending a message) for
further operations.

-- 
Best regards,
Igor Stasenko.