[rust-dev] RFC: New Rust channel proposal

Michael Neumann mneumann at ntecs.de
Fri Jan 24 01:53:27 PST 2014


Am 24.01.2014 04:16, schrieb Strahinja Markovic:
> On Thu Jan 23 2014 at 3:59:56 PM, Steve Klabnik 
> <steve at steveklabnik.com <mailto:steve at steveklabnik.com>> wrote:
>
>     I don't think that `new` not returning a `Channel` is a big deal.
>     Conceptually, you are, both ends 'make up' a channel.
>
>
> I agree it's not a big deal, but I still think it's something we might 
> want to change. Why introduce a mental speed bump if we don't have to? 
> Foo::new() returns a Foo, Bar::new() returns a Bar, Quux::new() 
> returns a Quux and a Channel::new() returns a... tuple of two items, 
> neither of which is a Channel (I know the two items together are 
> conceptually a /channel/, but they are not a Channel).
>
> Using new() here seems like a usability loss for no benefit. But 
> again, it's not a huge issue (should still be fixed though).
>
> Port & Chan are a bigger problem since users will forever have to 
> double-check which is which or will have to remember it.
>
> Why the cognitive load? Channel::new_pipe() returning (Source, Sink) 
> is a usability win we get for free.

I am against naming it Source and Sink. It doesn't comply with the verbs 
we use for sending and receiving, at least for me as a
non-native english speaker. While you can get/put something from/to a 
Source/Sink, you usually don't receive or send from a
Source or Sink. The names Port and Channel are ambiguous as well, but at 
least you can receive (e.g. goods) from a port and send
things on a channel.

Regards,

   Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140124/d602664c/attachment.html>


More information about the Rust-dev mailing list