Added: BO.Latest, fixed: BO.next, BO.mostRecent, BO.toIterable

[akarnokd]

• Implemented Latest (Issue Operator: Latest #59)
• Fixed Next and MostRecent to connect to the source observable only when the iterator is asked for.
• Fixed ToIterable.next() not properly handling the completed status (repeated calls to just the next() would simply block on the empty queue).

[cloudbees-pull-request-builder]

RxJava-pull-requests #557 SUCCESS
This pull request looks good

[zsxwing]

Using materialize to pack the all kinds of messages is better

[akarnokd]

I don't know. One less memory allocation seemed a good saving.

[zsxwing]

Using materialize and Notification makes the code clearer, doesn't it?

[akarnokd]

Yes, okay, I'll change things around.

[cloudbees-pull-request-builder]

RxJava-pull-requests #559 FAILURE
Looks like there's a problem with this pull request

[cloudbees-pull-request-builder]

RxJava-pull-requests #560 SUCCESS
This pull request looks good

[DavidMGross]

Does this capture the essentials, more-or-less, or should I draw up a more
complicated example with hasNext() calls?

https://raw.github.com/wiki/Netflix/RxJava/images/rx-operators/B.next.png
https://raw.github.com/wiki/Netflix/RxJava/images/rx-operators/B.latest.png

On Tue, Dec 17, 2013 at 1:11 AM, CloudBees pull request builder plugin <
notifications@github.com> wrote:

RxJava-pull-requests #560https://netflixoss.ci.cloudbees.com/job/RxJava-pull-requests/560/SUCCESS

This pull request looks good

—

Reply to this email directly or view it on GitHubhttps://github.com//pull/626#issuecomment-30735813
.

David M. Gross
PLP Consulting

[akarnokd]

I imagined something like these: next, latest

[DavidMGross]

Hmmm... It looks like I don't understand latest(). I figured the second
next() call in your latest() illustration would return the pink item, since
that is the latest unreturned item at the time the next() call is made.
Instead, you have it skip that one, and the red item emitted after the
next() call is made, and instead pick up the green item... I don't
understand the logic that governs this decision.

On Tue, Dec 17, 2013 at 12:32 PM, akarnokd notifications@github.com wrote:

I imagined something like these: nexthttps://docs.google.com/file/d/0B4T7ZW3brESKYllwckdxcG11TTg,
latest https://docs.google.com/file/d/0B4T7ZW3brESKSkt6cjUtSEhUX2s

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/626#issuecomment-30787987
.

David M. Gross
PLP Consulting

[zsxwing]

@DavidMGross I think your diagram is right.

[zsxwing]

The codes look correct and much clearer.

[akarnokd]

@DavidMGross this is due to the internal race between placing a value in the oNotif and removing one. So even if the next() has woken up, it still could be preempted, and a new Notification placed by onNext overwrites the previous value. Technically, the red item wakes up next(), but the green arrives just in time so it is emitted.

[benjchristensen]

Thank you for these fixes.