Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@BordedDev well, closing is the whole point, otherwise the compiler would force you to add a default case again.
In Swift it’s implemented as enums with associated values and there is an explicit syntax to open it for later modifications. -
@Lensflare Yeah and I hate it, just add the damn default or opt into closed ;P
I've had libraries I'd have to java-asm patch because they were written in kotlin and had everything closed -
@BordedDev yeah, it really depends on your perspective.
I know this feeling from C# projects. Often it's annoying when libraries hide or close the implementations and make customization or fixes impossible without hacks.
I see it that way: Java is optimized for writing libs. So everything is open by default.
C#, Kotlin and Swift are optimized for writing code that consumes libs, so everything is closed by default.
I rarely write lib code so I appreciate the closed defaults, because it really makes the code cleaner and sometimes even more performant and secure.
Related Rants
Lol @ Jetbrains
( ͡° ͜ʖ ͡°)
In Kotlin, I love sealed classes. They're beautiful. The compiler knows every possible subtype. When you use a when expression, it forces you to handle every single case. It's a closed, predictable, and exhaustive world. You can't have a random, unexpected state popping up at runtime.Then I look at my career. My path isn't a neat set of predefined subclasses like JuniorDev, SeniorDev, TeamLead. It's a chaotic mess of SideProjectThatBecameCritical, AccidentalSysAdmin, TemporaryScrumMaster, and ThatTimeIFixedThePrinter.The "when" expression of my professional life has a million unhandled branches and the compiler is screaming at me that there's no else block.
I just want a way to document all these weird, unexpected states so they look less like a series of runtime errors and more like a feature set.
random
kotlin