Consumers and Suppliers

[Brian Goetz]

Also, this request is kind of letting the tail (the way methods 
happening to be named in one particular collection implementation) wag 
the dog (names for function types.)

The java.util.function types are for naming *functions*.  A queue is not 
a function.

On 4/5/2013 9:17 AM, Vitaly Davidovich wrote:
> I'm with David on this one.  It's not that a queue is both at same time,
> but rather it's neither - it's just a handoff/communication channel between
> producers/consumers.
>
> I'd say a queue can be a message sink (receives) and message source
> (returns), but supplier/consumer is too close of a name to what people
> typically think of in that case, and it's not the queue.
>
> My $.02
>
> Thanks
>
> Sent from my phone
> I didn't mean that the collection was typically simultaneously a Consumer
> and a Supplier, I meant that it was typically one or the other (I should
> have been clearer in what I said). In my own collection library I do this
> and I find it very convenient.
>
> Sent from my iPad
>
> On 05/04/2013, at 12:54 PM, David Holmes <david.holmes at oracle.com> wrote:
>
>> On 5/04/2013 9:51 AM, Howard Lovatt wrote:
>>> If the method in Consumer was called put and the method in Supplier was
>>> called take, then Queue could be retrofitted to extend both Consumer and
>>> Supplier and then many collections could be Consumers and Suppliers.
>>>
>>> I think this would be useful - what do others think?
>>
>> I would find that rather confusing because in the common
> producer/consumer sense the producer puts things into the queue and the
> consumer removes them from the queue. The queue itself is not considered to
> be producer/supplier nor consumer.
>>
>> David
>>
>>>    -- Howard.
>>>
>