hey, a bug report was submitted to me with something that looks like this: ```sealed class Foo : Som...

# getting-started

[y]

hey, a bug report was submitted to me with something that looks like this:

sealed class Foo : SomeInterface1, SomeInterface2 {
    @kotlinx.serialization.Serializable
    object A : Foo() {
        private fun readResolve(): Any = this
        override fun hashCode() = /* ... */
    }

    @kotlinx.serialization.Serializable
    object B : Foo() {
        private fun readResolve(): Any = this
        override fun hashCode() = /* ... */
    }

    @kotlinx.serialization.Serializable
    object C : Foo() {
        private fun readResolve(): Any = this
        override fun hashCode() = /* ... */
    }

    fun doTheThing(baz: List<String>): String = when (this) {
        A -> /* ... */
        B -> /* ... */
        C -> /* ... */
    }
}

the bug report was a kotlin.NoWhenBranchMatchedException thrown from doTheThing(). how could this be? is this necessarily a kotlin bug?

[Sam]

I have sometimes seen issues like this when using mocks in tests. If a mocking framework is generating an implementation of Foo, it could end up with an instance that isn't one of the required subclasses.

[Youssef Shoaib [MOD]]

Use data object instead of object. What's happening is that the object is being recreated I think

[y]

@Youssef Shoaib [MOD] I didn't know about that feature, interesting. however, going over the feature description, it seems like this is only syntax sugar for auto-implementing toString(), equals() and hashCode(), right? so if if we already implement hashCode() (hopefully correctly) and even readResolve(), would there be any difference with using a data object?

@Sam thanks - no mocking involved afaik

[Youssef Shoaib [MOD]]

equals is what matters here I believe. That's why the when is failing

[Youssef Shoaib [MOD]]

Try replacing A -> B-> etc with is A-> is B-> and that should also work, because a data object's equals simply does an is check

[y]

oh, I see. is this fixable without going to 1.9 (which we might not want to do - not my decision)? is it as simple as adding the following boilerplate?
override fun equals(other: Any?) = hashCode() == (other as? A)?.hashCode() (and same for B and C)

[y]

or even override fun equals(other: Any?) = other is A (and same for B and C)

[y]

...and if that works, then surely your is A -> solution would work without 1.9

[Youssef Shoaib [MOD]]

Yes the is check should do the trick, but make sure you override hashcode as well

[y]

@Youssef Shoaib [MOD] just to be clear - the minimal change here would be to add is A -> branches in the when? no equals() override required?

[Youssef Shoaib [MOD]]

Yes that's the most minimal change you can make, just is A ->

[y]

I see. thanks a lot.

[Klitos Kyriacou]

By the way, comparing hashcodes is not the right way to implement equals. Two objects are allowed to have the same hashcode even when they're not equal.

[y]

@Klitos Kyriacou yes, however the as? check would then return null in that case (which means, the actual equality here is on the type and the check with the hashcode is superfluous)

[Klitos Kyriacou]

Even then, if this.hashCode() happens to return 0, it will equal null.hashCode() so will give an incorrect true result.

[y]

woah, that's right!

[Klitos Kyriacou]

Actually, I misread it: (other as? A)?.hashCode() would be null?.hashCode() so it will be comparing 0 with null, which is false so it would give the right answer anyway.

[ephemient]

object doesn't override equals, so it doesn't rely on `hashCode`; it's purely the default equals, which is instance-based

[ephemient]

there should not be any way of creating instances of object in pure Kotlin, but it can happen through Java serialization or reflection

[ephemient]

(which mockk and other mocking libraries do under the covers)

[y]

so (as previously mentioned), would is be the preferred way of making sure all instances of the same `object`s test the same?

[ephemient]

it's a bit awkward but yes

[Youssef Shoaib [MOD]]

Easiest way is to use data object it handles all of that because it overrides equals and hashcode

[ephemient]

you can do some tricks with readResolve to ensure Java serialization doesn't return non-singleton instances, if you think that's what your users are running into, but there's no way to protect against reflection

[ephemient]

oh wait I notice you already have readResolve

[ephemient]

that doesn't look like the right way to do it though

[y]

we do believe this is a serialization thing (by "we", I mean people here more knowledgable about this than me)

[ephemient]

currently your readResolve is simply passing through the newly-created instance. instead it should look like

object A {
    private fun readResolve(): Any = A
}

if you want to ensure that only the singleton A.INSTANCE exists (after the serialization machinery)

[ephemient]

also, it's an API/ABI change, but if you wrote

enum class Foo : SomeInterface1, SomeInterface2 {
    A,
    B,
    C,
}

then Java serialization will just work

[y]

@ephemient that readResolve() implementation is probably it! thanks for catching it