[squeak-dev] Re: [Newbies] Two questions about Smalltalk language design

Andreas.Raab andreas.raab at gmx.de
Thu Jan 3 12:58:34 UTC 2013


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-design-tp4660938p4661885.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.


More information about the Squeak-dev mailing list