What does a Consumer consume?

[Zhong Yu]

On Thu, Apr 11, 2013 at 4:09 AM, David Holmes <david.holmes at oracle.com>wrote:

> On 11/04/2013 6:19 PM, Thomas Münz wrote:
> > Bike shedding alert :)
> >
> > While I think Java 8 is pretty optimal from what I saw so far (I know it
> can't be perfect considering Java history), there's one particular thing
> that worries me so much that I feed compelled to bother you with it.
> > Please bear with me.
> >
> > I strongly appeal to rename the type Consumer to a more approriate name,
> like maybe Procedure.
>
> See the following
>
> "Let's please rename Block to Receiver before it's too late"
>
>
> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-January/001136.html
>
>
In that thread there were a lot of support for "Procedure", which
unfortunately wasn't included in the survey. (supporters: Doug Lea/Raab,
Donald/Tim Peierls/Joshua Bloch/Sam Pullara/Joe Bowbeer/Jonathan Finn)


> "Hopefully the last message on Block"
>
>
> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-January/001215.html
>
> David
> -----
>
> > Rationale follows:
> >
> > A consumer is an entity that consumes another entity, meaning removes it
> from its context. Best example is a collection that is used for
> inter-thread communication: the producer/supplier thread puts a new item in
> the queue and the consumer thread removes the item from the queue, hence
> _consumes_ it.
> > Consuming generally implies that the entity it is applied to is
> _consumed_, made gone, removed. Also see the meaning of consumer in the
> economy: consumers (we) take and buy stuff, remove things from their shelf
> and then use/digest/etc. them until they're gone.
> > But this core meaning of the term is absolutely not the case with the
> functional type that currently carries this name. It's just a procedure,
> not a consumer.
> > It MAY be used to consume entities from a collection (which depends on
> the method called, not the passed function instance), but it may and will
> be used many times more to just iterate them and apply a logic to them in
> general busines logic.
> >
> > I must say was very happy to see that the old,
> compiler-specific-oriented name "Block" has been given up (already wanted
> to post about it, but the problem solved itself, thankfully).
> > But only to be replaced by an apparently concurrency-specific-oriented
> name like "Consumer".
> > But why not just take the general functional way of thinking to find a
> name for a general functional element in the first place?
> >
> > Can('t?) you imagine the hundreds of questions from beginners and not so
> talented developer colleagues like "If I apply the consumer to the
> collection, is the collection empty afterwards?"? ... and the hundreds of
> times we will sigh, start explaining "No, you see, this is just a ..." and
> think "why oh why did they give it that name?" and then start to explain
> time and time again?
> > This won't be a sign of missing understanding of the asker, but it's a
> sign for confusing naming in the official API.
> >
> > Also, a very good indicator that Consumer is an unlucky choice can be
> found in its own JavaDoc:
> > "An operation which accepts a single input argument and returns no
> result."
> > If you instantly have to switch to another term to even begin to explain
> it, then why did you chose the unfitting term in the first place? Why not
> then call it "Operation" right away? Or as "Operation" might be ambiguous,
> something even more fitting, like said "Procedure".
> > And again: where is the reference to the name, to the process of
> consuming in the java doc? It's missing for a good reason: because nothing
> is consumed in the first place.
> >
> >
> > I have function types in my own (sry: next generation start-over)
> collection framework that I use very successfully for years now, namely:
> >
> > Predicate<E> with boolean apply(E)
> > Function<I,O> with O apply(I)
> > Procedure<E> with void apply(E)
> > (Plus a couple of others like Aggregator<E, R> extends Procedure<E>
> which for me is a much more elegant, flexible and efficient concept than a
> reducer, but that doesn't matter here much).
> >
> > Those are very thoroughly thought through names, based on the following
> rationale:
> > 1.) Procedure correlates very good with the other type Function when it
> comes to building the mental conception of different functional types.
> > They are both very similar, but Function returns something, Procedure
> does not. Like "brothers". Very intuitive, very straight forward. At first
> I named it "Operation" (like mentioned above), but because of this point,
> procedure appeared to be much more fitting.
> > 2.) All the functional types have a unifiedly named method "apply". A
> function is applied to an entity. A predicate can apply to an entity
> (honestly: who says "the predicate tests the entity" in common speaking? I
> think 90% say "if the predicate applies to the entity, then...")
> > As a side node: colliding method names are irrelevant because in
> practice you never come accross a case where a concrete implementation has
> to implement a procedure and a predicate or so. Such cases are done by
> internal separated delegates anyway, not by directly implementing multiple
> interfaces.
> >
> >
> > Me personally (however much that is worth), I will happily delete my
> proprietary "Function" and refactor everything to use the standard one the
> moment Java 8 goes live. I'm all for standard conformity if it's at least
> "okay" to use it.
> > I'm currently struggling with myself to accept the standard Predicate
> with it sub-optimal "test()" as well for sake of standard conformity, but I
> think I'll get there in the end.
> > But I cannot in good conscious replace an intuitive, easy understandable
> "Procedure" in my private and professional work with a confusion-prone
> "Consumer" and explain my customers and colleagues endless times that it
> doesn't really do what it implies but instead is just an ordinary
> procedure/operation/routine. The reaction of anyone having even a little
> reservation about functional programming will instantly be "Aha, this
> doesn't sound very thought-out, I knew it, functional programming is crap,
> go away".
> > I'd rather stick to my proprietary Procedure type and tell them to
> better not use the standard mechanism from the JDK because it does more
> harm than good. Sadly, I do this a lot and I hate to do it every time.
> Maybe this time, I hope I can prevent it ...
> >
> >
> > Alternatives fitting the concept instead of Procedure might be "Routine"
> or even more abstract "Logic" or "Action", but really, please consider that
> in practice, on a daily business logic designing level instead of a
> language design working bench, "Consumer" is the second worst and confusing
> choice right behind "Block". Why not pick a term from the upper end of
> fitting terms instead of the lower end and save everyone several tons of
> hazzle in the coming years?
> >
> >
> > Thank you for your attention.
> > Regards and thanks very much for the 99% pretty optimal rest :-). Can't
> wait to see it go live.
> >
> >
> >
>
>