Igor Stasenko wrote
On 3 January 2013 03:56, Eliot Miranda <
eliot.miranda@
> wrote:
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.
But in general, the problem lies in delegation. As long as you return the receiver of the message the return is simple. But if the receiver delegates to another object along the lines of:
doSomethingWithFoo: arg "Do something with my ivar foo and the argument" ^foo doSomethingWith: arg
then the implicit return of self from foo will cause you to create excess proxies. Much better to return nil. You can still proxy nil as a "real object" if you really want to treat remote nil different from local nil (although I've never found a situation where this proved useful).
One real-world example of how implicit returns negatively affect distributed systems, we found that in Croquet, the implicit return from blocks would create a ton of garbage promises that were never used. For example, if one were to write:
foo ifNotNil:[foo future yourself].
this would create a (completely useless) promise for the future as it would be referred to as the result from the block. We changed this so that futures that were the last statement of a block return nil and do not create a promise (and nobody ever complained :-)
Also, note that the problem would be compounded if the return would require a network round-trip too (in Croquet it doesn't); in this case you pay for the promise and for proxying an implicit self return from some completely uninteresting object that nobody will look at afterwards.
The negative effects of implicit returns are definitely noticable in distributed systems when you're trying to utilize proxies efficiently. Knowing when (not) to create a proxy and when (not) to return an object is a major help in making the system efficient.
Cheers, - Andreas
-- View this message in context: http://forum.world.st/Re-Newbies-Two-questions-about-Smalltalk-language-desi... Sent from the Squeak - Dev mailing list archive at Nabble.com.