Let's please rename Block to Receiver before it's too late

[Tim Peierls]

I don't know what BiSource means, but the rest seems reasonable.

On Sat, Jan 19, 2013 at 10:17 AM, Kevin Bourrillion <kevinb at google.com>wrote:

> Source<String>
> IntSource
> DoubleSource
>
> Sink<String>
> IntSink
> DoubleSink
>
> BiSource<Foo, Bar>
> ObjIntBiSource<String>
> BiSink<Foo, Bar>
> ObjIntBiSink<String>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130119/bbba8094/attachment.html