Good idea. How about Channel::new_ends() returns (SendEnd, RecvEnd) ? 2014年1月24日 上午6:57于 "Val Markovic" <v...@markovic.io>写道：
> On Thu, Jan 23, 2014 at 2:32 PM, Vadim <vadi...@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 >> <bander...@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@mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
