null object pattern

sealed classes are really good for representing multiple return types

think shuffling a deck of cards.

fun observeShuffles(): Observable<ShuffleOperation>

sealed class ShuffleOperation {
    //when deck is in the process of being shuffled
    object Shuffling : ShuffleOperation()

    //an error happened when shuffling the deck
    class Error(val description: String) : ShuffleOperation()

    //successfully shuffled deck
    class Shuffled(val deck: Deck) : ShuffleOperation()
}

Interesting. Like this?:

sealed class Option<A> {
	class Some(val value: A): Option<A>
	object None(): Option<A>
}

yup!

with when's you can force yourself to be type safe for every variation of the sealed class

but data class may be simpler since it's just a nullable

sealed classes let you scale to 3 or more implementations

There's a problem with the None object, I can't give it a type.

Yeah, I guess the data class will work for my usecase just fine.

you would use a sealed class to handle a specific call

like for a specific shared preference

Hm, I'm not sure. I mean, for all preferences the situation is the same: It may or may not contain a value. Wouldn't it be better to use the Optional for all of them? What would be the advantage of having one per specific shared preference?

I'd use the optional, because it's faster

I would only use a sealed class when there's 3 or more different implementations. When reading a shared preference, only two options are possible - preference exists or it doesn't

sealed classes are also more descriptive

sealed class User {
  class LoggedIn(....) : User(),
  object NotLoggedIn : User()
}

with sealed classes you could represent a user not being logged in, attaching the reason why the user isn't logged in, etc. You couldn't do that with an optional or nullable type

Here's a project I started using heavily at work: RxKotlin-JDBC which is inspired a lot by RxJava-JDBC. Please feel free to share your input or ideas. I got a working prototype already that I'm hoping to solidify. https://github.com/thomasnield/rxkotlin-jdbc

I am looking for feedbacks about

reactor-kotlin-extensions

since I will shortly release

1.0.0.M1

. Feel free to test, creates issues or submit PR. https://github.com/reactor/reactor-kotlin-extensions

can i get feedback on if i can further simplify this rewrite of a rxjava utils class to kt?

i am a novice with kotlin. amazed at what i have seen so far. i feel like i can probably get this much cleaner once i understand the lang features better!

is it possible to infer the T parameters here for example?

@mutexkid you can remove the explicit return types, if that’s what you’re after:

private fun applySchedulers() = this.subscribeOn(…)...

but personally, I prefer to explicitly declare the types if the field or function is public. As for the type parameter declaration

<T>

, you may want to set it to

<T : Any>

instead to ensure it only accepts and returns non-nullable types

Hi, just curious does anyone know what the rationale for RxJava 2.0 banning nulls is?

To closer match the reactive streams spec

See https://github.com/ReactiveX/RxJava/issues/4644#issuecomment-256684743

yeah I saw the lingo

Ill read that issue

I though it was a very odd thing when the wiki suggested using “marker objects: