What's difference and when should each be used? :thinking_face: ```sealed class Fruit object Apple :...

# announcements

[Andrew]

What's difference and when should each be used? 🤔

sealed class Fruit
object Apple : Fruit()
object Banana : Fruit()

vs

sealed class Fruit {
   object Apple : Fruit()
   object Banana : Fruit()
}

[ephemient]

in older kotlin only the second was an option

[ephemient]

in newer kotlin choose whatever makes more sense for your code structure

[Nir]

I think it's purely a scoping, aesthetic difference, no? In the former case you'll refer to Apple and Banana, in the second, Fruit.Apple and Fruit.Banana

[wbertan]

One you access as just Apple for example, while other you use Fruit.Apple.
So if in the same scope you have like Brands with Apple too, the first example will complain as you would have two Apple objects, while the second should be fine as you access as Brands.Apple.

[Nir]

In this example, taking it literally, I would use the first one because I know that Apples and Bananas are fruits. When I always want the name of the base as context, I choose the second.

[wbertan]

We use the second example more often for example in ViewModels Events for Android, as we sometimes scope Events for a specific ViewModel, but sometimes they have same name like ViewModelAEvent.Navigate and ViewModelBEvent.Navigate

[Andrew]

Thanks for responses folks.

The question was provoked when doing refactoring for code similar to the example @wbertan has mentioned about view model events 🙏 I had been changing to the nested approach but I couldn't justify it past 'it better describes similarly named classes'

[Michael Böiers]

@ephemient “older kotlin”? Using 1.4.32, and only the second b lock works. 🙂

[ephemient]

@Michael Böiers really? it should work since Kotlin 1.1 as long as it's in the same source file. Kotlin 1.5 ads the ability to write them anywhere in the same module and package.

[nanodeath]

I thought the first form was more recent, like 1.3

[ephemient]

works on playground's 1.2, so it's at least that old

[Michael Böiers]

You’re both correct, @ephemient and @nanodeath. It doesn’t work for me in an IDEA scratch file. Don’t know why, from all I can see I am using Kotlin 1.4.

[ephemient]

https://kotlinlang.org/docs/whatsnew11.html#sealed-and-data-classes

[ephemient]

doesn't work for me in ki-shell either, so I guess there's just something about kotlin's scripting engine that doesn't work well with that type of sealed class declaration

[ephemient]

maybe it has to see the whole file to determine permitted subclasses, but interactive shell / scratch files are processed iteratively, or something? I don't know.

[Michael Böiers]

I have a suspicion: Apparently the code in a scratch file / Kotlin script is embedded in a class.

[Michael Böiers]

So if you try to define a sealed class in a scratch file, you’re really defining a nested sealed class, and that leads to the problem. So this is what’s happening in the scratch file, and it doesn’t work in general.

class Foo {
    sealed class Fruit
    data class Apple(val name: String): Fruit() // Fruit is not accessible
}

[ephemient]

wow, good investigation. might be worth filing a YouTrack issue to see if they can fix that

[Michael Böiers]

It’s definitely annoying because I was demonstrating Kotlin to co-workers. At the very least it would be good to know what the limitations of the scratch file / scripts are. 🙂