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

Kevin Bourrillion kevinb at google.com
Sat Jan 19 07:24:04 PST 2013


Well, now that's an interesting point.  I got caught up in the excitement
of BiEverything.



On Sat, Jan 19, 2013 at 7:19 AM, Tim Peierls <tim at peierls.net> wrote:

> 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
>>
>
>


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com


More information about the lambda-libs-spec-observers mailing list