Message-Passing

[Manu]

On 26 January 2012 22:07, Sean Kelly <sean at invisibleduck.org> wrote:

> On Jan 25, 2012, at 2:49 AM, Manu wrote:
>
> > On 23 January 2012 02:00, Timon Gehr <timon.gehr at gmx.ch> wrote:
> > Erlang *has* been used in multiple large projects and it is likely that
> you make use of some service that is powered by erlang on a daily basis. It
> is successful in its niche. Copying its message passing API is reasonable
> and safe: Its concurrency model is the main selling point of erlang.
> >
> >
> http://programmers.stackexchange.com/questions/112417/real-world-applications-of-erlang
> >
> > Oh come on.. It's niche, unfamiliar to most people, and we're talking
> about name and argument list clarity with respect to what would be
> instinctive to the most users, not 'model' or API design, that's obviously
> fine.
>
> Personally, I expected receiveOnly to see infrequent use compared to
> receive.  At least in my own code, it's rare that I'd want a receive call
> to throw if there's any message in the queue other than the one I'm looking
> for.  So the naming scheme was a mistaken assumption of popular use.
>

Well perhaps my usage is biased, but I think many/most threads are spawned
with the intent of receiving one particular workload from one source. I
think a thread that receives a variable/dynamic workload is probably less
common, although certainly does exist, but regardless of that, from the
point of view of API design, I don't think the API clearly communicates
that intent. It certainly had me scratching my head until I _read the
docs_, which is the basis of my argument.
If I'm wrong on that point, then there's nothing to argue :)

(bear in mind, this isn't the only thing I mentioned in my OP. As with
prior posts where I've made the mistake of listing things, the the single
most trivial detail in my list is the one that spawns the longest
conversation ;)

> C# is awesome because it gets this right. I think that's its single
> > greatest achievement, and can not be understated.
> >
> >
> > I couldn't find any information about a C# API for the same
> functionality. Can you help me out?
> >
> > I'm not referring to this API in particular, I'm referring to the fairly
> universal application of the principle within the C# libraries. Most people
> I've ever talked to agree that one of it's biggest selling points, and
> possibly even the key reason they use it; because it was so accessible and
> productive from the instant they tried it out.
> > You shouldn't need to read anything. Pressing '.' in the IDE shows lists
> of classes/methods/etc, and common sense writes your code. This requires
> that the function names make perfect sense, and the argument lists are as
> you intuitively expect.
> >
> > If I: send(tid, myThing);
> > I expect to: myThing = receive!SomeThing();
> >
> > How can you argue that it's not intuitive to receive what you sent?
>
> We could overload receive even more so that if it has only one argument
> and that argument is not a callable type, it does receiveOnly.  That might
> be deceptive however.


I agree that's a pretty ugly approach. I can see your point, but it only
makes sense to me with advanced knowledge of the API. If I approach it
without that insight, as I did, it's not so clear, or even misleading.
Consider the position you're likely to be when you reach for the API,
trying to use it for the first time, and you've just typed: send(tid,
myThing) not 10 seconds prior... what do you expect to type next?


> What I like about "receiveOnly" is that the name itself suggests that
> anything other than the specified type is not expected, and so some measure
> will probably be taken.


Again, this only makes sense to me if you already expect that the act of
receiving (as a compliment to the send API, which you've already invoked
and have a presumption about), was capable of receiving any/multiple
things, rather than receiving what you just sent a few lines back...

 receive!T says to me "look for a message of this type and block if it's
> not present."
>

Perfect. It says that to me too. I'm lost now though, this is the behaviour
of receiveOnly... are you agreeing now? :)

> There's nothing in: send(tid, something); that suggests the expected
> compliment API should take a var-arg list of undefined things. It's not
> clear from receive()'s signature that it should receive delegates, it looks
> like it could receive anything. The delegate signature is un-knowable from
> the functions own signature, nor what the delegates are even supposed to do.
>
> This is an artifact of templates.  I doubt C# has this issue because C#
> doesn't have templates.
>

C# has generics. Not quite like D templates, more like C++, but still...
But in a case like this, such an apparently arguably ambiguous API wouldn't
be permitted. It would be restructured, or the competing API's both renamed
to something more clear.

> Also, the name 'receiveOnly' doesn't actually make sense unless you
> *already know* that receive() is effectively receiveMulti. If I was
> scrolling through the pop-up list of methods, I would not confidently
> predict what that does.
>
> Matter of opinion I suppose.  See above.


Perhaps so. I suppose my mental flow was by drawing a direct contrast to
the send() API, which I called not 10 seconds prior, before trying to type
my receive code.


Anyway, I think it's a void topic in this instance, it's been stated that
it will not change, I'm good with that.
I was just trying to raise the point that I think more care should be taken
to the end that the standard library (across the board, not just in this
case) should be indisputably intuitive, and with particular consideration
to auto-complete listings, which should be self evident enough to do most
basic functionality a system offers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120126/974b6379/attachment-0001.html>