[dmd-concurrency] draft 4

[Steve Schveighoffer]

----- Original Message ----

> From: Andrei Alexandrescu <andrei at erdani.com>
> 
> Sean Kelly wrote:
> > I haven't been able to come up with any difference in implementation for using 
> an interface vs. a free function that accepts an opaque type for sending 
> messages, so the choice seems largely a matter of how you want the call to 
> look.  I'll admit that I like "send(tid, thisTid, i)" since it matches 
> "receive(...)" but this is a small thing really.
> 
> You're echoing my thoughts as I was writing this. I'm undecided wrt 
> tid.send(...) vs. send(tid, ...). I agree it is more symmetric with receive. 
> Probably I'll use the free form. Other opinions?

receive is short for thisTid.receive.  I think it is symmetric with tid.send, but since you need to identify the address for sending, it is required on send, not on receive.  It's the same as not requiring "this" inside a member function.  One thing I like about tid.send(...) vs. send(tid, ...) is it separates the message from the target better.  send(tid, 1, 2,3) looks like you are sending tid, 1, 2, and 3 somewhere, not that you are sending 1, 2, and 3 to tid.

One caveat however, receive may be a commonly used function name.  The benefit of tid.send is that the namespace is identified.  Would it be bad to require receive be thisTid.receive?  That provides symmetry and takes care of any namespace issues.

also, shortening the receive name might look better if you identify what object you are receiving on (e.g. thisTid.recv()).  recv may look awful, but it's not unprecedented, and it's pretty hard to misconstrue the meaning.  I think short names are warranted when the function is super-prolific (as I'd hope message passing would be) and the shortened version is hard to confuse with another meaning.  Compare writefln to writeFormattedLine.  I think it's roughly the same.

-Steve