For me this looks like an unnecessary complication. Or maybe I’m missing something?

@gregd because in JavaFX, a

ComboBox<T>

is not a

ComboBox<String>

. It can be anything

Type safety and the API design of JavaFX makes it what it is.

I think some people are a bit too harsh about nulls sometimes, including that JodaTime guy who recently wrote an article saying an API should never return them. If nulls didn't have a place in the new programming landscape, Kotlin would have just banned them altogether rather than having a nullable type.

I think we’re stuck with null because of java interop

@gregd hmmm... interesting thought. I need to digest that...

But I get your point with JavaFX

About nullability, I don't know if that's true at least if you use Kotlin as gospel. If it was believed nulls should have been banned in Kotlin, they would have been. Rather than having a platform type, Kotlin would have forced you to convert a Java null value to something else or simply error out. Unless there's something about the JVM I don't know about that required nulls to be acknowledged in Kotlin...

But one of the core principles of Kotlin was to work seamlessly with Java - without any conversions or whatsoever. It’s one of those things that distinguishes K from the majority of other JVM languages

@gregd if that's the case, maybe. But even pure Kotlin operators on collections and sequences, such as

min()

and

max()

, return nullable types if the source was empty.

Vacuous state is inevitable. You should avoid them where possible, but sometimes you simply can't express nothing with something.

@User uploaded a file: Untitled

Well, of course you have to have something that indicates “no value”, but it doesn’t necessarily need to be null 🙂

Some variation of Option would do the job

But, anyways, we’re stuck with null for some time… 😄

I see what you're saying now, we might be arguing on the same side.

I forgot to share with this channel, I've been using this pattern a lot recently. It's a quick-kill

replay()

operation that will immediately invalidate a cache and replace it with a new one on every upstream emission.

I wonder if there is a way to package this up in an operator. It's like a

switchMap()

that replays each resulting

Observable

.

Interesting. Is returning an Observable from map() instead of flatMap() intended?

Yup. Looks like it is 😉

@gregd yes

Because you are making the replayed Observable the emission. Deferring subscription to it after the outer

replay()

allows you to replace it immediately

What I don’t like in this approach is that the stream is finite, and is subscribed to multiple times. I tend to implement the whole stream logic by subscribing to all streams once at the beginning of the app. And after that everything “magically” works by itself.

But it might be that I just need to spend more time investigating your example 😄

True, and I guess there is a possibility this need might be specific. I'm using this to store a finite dataset that is pushed to every interested Observer at a given time. But I want to kill it immediately and rebuild it for all future Observers at that moment, and eliminate risk of obsolescence upon validation.

I use this primarily for reactive business data models

In a TornadoFX UI

And that is valid about zipping everything you need at the beginning, but I've found this is a good way to separate operations a bit more easily.