[rust-dev] RFC: New Rust channel proposal

Val Markovic val at markovic.io
Thu Jan 23 14:56:56 PST 2014


On Thu, Jan 23, 2014 at 2:32 PM, Vadim <vadimcn at gmail.com> wrote:

> Well maybe then channel() -> (SendEnd, RecvEnd) ?   Or, channel() ->
> (Source, Drain) ?
>

When there are two concepts, one for "data comes out of this" and one for
"data goes into this", the names I have most often encountered are "Source"
and "Sink". They're pretty descriptive; you immediately know which end is
which. "Source" and "Drain" serves the same purpose as well.

"Port" and "Chan" are IMO really bad names. Neither tells me anything about
does it accept or provide data. "Chan" especially, since conceptually a
channel is the conduit between a source and a sink.

Like Brian said, three concepts are involved here. Good names would be
"Source", "Channel" and "Sink", all three of which are descriptive. No
explanation is necessary to understand what's behind the names and no
memorization is required.

Channel::new() returning a Source and Sink would be an improvement, but it
breaks the mental model of "Type::new() creates a new Type" from the rest
of the codebase.

We need a different name than "new" for this. "Channel::pipe()" is better,
but since function names are often verbs or start with verbs, it implies
not that a pipe is being built, but that the function accepts something
that is piped through the channel.

Channel::new_pipe() returning a (Source, Sink) seems ideal. "new" as the
word before "pipe" would be a good choice because it's suggestive of how
"new()" in other types builds the type.


>
>
> On Thu, Jan 23, 2014 at 12:33 PM, Brian Anderson <banderson at mozilla.com>wrote:
>
>> On 01/13/2014 10:15 PM, Liigo Zhuang wrote:
>>
>>> People should rethink the Chan api that Chan::new() does not returns a
>>> value of type Chan (instead, a tuple), which is strange, and inconsistent
>>> with other Type::new().
>>>
>>>
>> Agree, though I haven't heard any great suggestions yet. The core problem
>> is that there are three different entities involved: the sending end, the
>> recieving end, and the thing that represents the entire channel, and they
>> all need different names. The best I've heard is `pipe() -> (Port, Chan)`,
>> but I would rather call the whole thing a channel and have a different name
>> for the sender.
>>
>> _______________________________________________
>> Rust-dev mailing list
>> Rust-dev at mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>
>
> _______________________________________________
> 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/20140123/696d8e4d/attachment-0001.html>


More information about the Rust-dev mailing list