Let's please rename Block to Receiver before it's too late (original) (raw)
Kevin Bourrillion kevinb at google.com
Sat Jan 19 07:17:23 PST 2013
- Previous message: Let's please rename Block to Receiver before it's too late
- Next message: Let's please rename Block to Receiver before it's too late
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Source IntSource DoubleSource
Sink IntSink DoubleSink
BiSource<Foo, Bar> ObjIntBiSource BiSink<Foo, Bar> ObjIntBiSink
I think this is as good as we're going to get and, with Receiver failing to catch on, I'd like to see if we can converge on Source/Sink now; who's in?
On Sat, Jan 19, 2013 at 7:10 AM, Doug Lea <dl at cs.oswego.edu> wrote:
On 01/19/13 09:58, Tim Peierls wrote:
I agree that "sink" doesn't emphasize the side-effect aspect, but does it really need to? What other use could a sink have? Whereas "action" doesn't carry any sense of "consuming" or "accepting".
Right. That's why it is nice in streams, but not in cases where the connotation of consuming is just plain wrong -- the argument is just "used" not "consumed". a.accept(x); b.accept(x); doSomethingElseWith(x); My reason for preferring Action (or even Block!) to Sink is that the only commonality is potential (and extremely likely) side-effecting-ness. (What would you name a void action of two arguments? There are a lot of these now.) -Doug
-- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
- Previous message: Let's please rename Block to Receiver before it's too late
- Next message: Let's please rename Block to Receiver before it's too late
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the lambda-libs-spec-observers mailing list