Subscription.requestMore

[benjchristensen]

Any particular reason for the "more" in requestMore?

public void requestMore(int elements);

It seems redundant to have "more", or non-applicable on the first invocation of it when nothing has yet been requested hence "more" is wrong.

Perhaps it's cleaner to just say:

public void request(int elements);

[viktorklang]

Yeah, we thought about that at first, sadly it was too easy for people to think that you could "change your mind" by first doing "request(50)" and then "request(30)" and expect only 30 to be obeyed.

requestMore is extremely explicit about the expectations. Makes sense?

[benjchristensen]

No it doesn't make sense. It is invalid to request "more" when nothing has yet been requested and having "more" does not communicate semantics of "change your mind" any better than "request" does. Once a request is submitted of course you can not "change your mind".

[viktorklang]

Fair enough, how about requestNext(int numberOfElements)?

[benjchristensen]

I just don't see why we need a suffix to "request". It comes across as unnecessary noise.

[viktorklang]

@benjchristensen I'll make you a deal, let's just call it more :-)

[jbrisbin]

@benjchristensen @viktorklang this is why on the other issue I brought up the idea of hasMore(int) which seems to be apropos here.

I also am a little sketchy on the "request" part of the method name because that IMO implies a return value. Like I'm requesting a certain number of elements be returned to me, which is not what's happening.

[viktorklang]

@jbrisbin It's not a question if it has more or not though. It's a signal of demand: "I request that you give me N elements"

What about demand(int elements) or perhaps onRequest(int elements)?

(As an aside, shouldn't we focus less of our energy on bikeshedding names and more on semantics :-) )

[jbrisbin]

@viktorklang names have importance because they should signal intent. The names should be the semantics as far as possible. So I understand the notion that names aren't important but I disagree: names are everything. :)

I get the the signal of demand thing. I just doubt that it's enough to make an informed decision about what to do if N elements aren't available. I fear the situation will be the same as blindly creating Iterators over empty collections which is simple to do in code but extremely expensive in practice while under load.

[rkuhn]

@jbrisbin I’m with you concerning clarity of naming and accordance with intent: what the method shall express is “signal additional demand for N units”, which is very clear. Shall we name it such?

BTW: I do not understand how empty collections enter the picture; sending demand has nothing to do with its fulfillment. It is rather unfortunate that there is such a big semantic gap between demand (n) and “to demand”. Unfortunately the alternatives are even worse—wish, desire, want, …

[viktorklang]

@rkhun crave(int)? perhaps order(int)?

[DougLea]

Or, just more(int)

(which I was about to suggest in one of my first posts before Viktor convinced me to stay out of bikeshedding...)

[viktorklang]

@DougLea Haha, ok, so another one for more :-)

[rkuhn]

I’d have to disagree: request bears closer relationship to the desired meaning than more (which is quite an unusual method name ;-) ).

[DougLea]

Apparently unusualness is what we want, to avoid misinterpretation.
Also, you'd pronounce more(1) as "more!", and more(2) as "more!!", and ...

[viktorklang]

@DougLea There's also the opportunity for gimmeh with great-reading code like

gimmeh(5)

[JakeWharton]

+1 to "more" being strange and to simplifying to just request.

[normanmaurer]

I think I would also vote for request

[rkuhn]

summing up: three votes for request (Ben, Norman, myself) so far. @jbrisbin @smaldini @mariusaeriksen ?

[benjchristensen]

This change is included in #40