[rust-dev] RFC: New Rust channel proposal

Lee Braiden leebraid at gmail.com
Fri Jan 24 04:01:53 PST 2014


I regularly send/receive things to/from channels at work, and it seems 
you can do the same with real-world ports.

I really have no idea what Rust means by a port does, vs. what it means 
by a channel, without reading the details in docs.  I'd assume the port, 
channel ordering reads left-to-right like most english, and so equates 
to send, receive, but that could be a very dangerous assumption.

As you can tell from the above, I haven't gotten into using channels 
yet, or knowing the API in detail, but it's one of the things that 
attracts me to Rust, so I will eventually.  My gut instinct so far, 
based on limited understanding of what you're trying to represent, is 
that the API should probably be broken down into clearly distinguished 
"Channels", "Connections", and "Source"/"Sink" "ends" to those 
connections, even if that requires a channel to provide two pairs of 
sources/sinks for send vs. receive (or just some method which returns 
these things, swapped around, as a hidden implementation detail).


-- 
Lee

On 24/01/14 09:53, Michael Neumann wrote:
>
> 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
>
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev

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


More information about the Rust-dev mailing list