> And I don't need any of the tools you mention because it does the right thing by default.
I mostly agree with you, but Spring+Kotlin does require the allopen plugin, so it's kind of hacking Kotlin to do the wrong thing (all classes open) in order to support an arguably bad design choice by Spring.
A whole lot of pie in the sky architects, which seems to be all of Kotlin authors and all of Kotlin-writing cadets, sure love to dream that closed by default is a good design choice and think of times when something open was extended or accessed that wasn’t actually consciously fore-thought of the intended points of extension. But they conveniently ignore the costs of these shackles to their business and agility, and I argue that the costs are far greater than the benefits, especially for non-library code. We just spent a couple of decades fighting the waterfall delusion of big design up front. Yet closed-by-default takes us back to the Stone Age that ignores the reality that there’s no way that the original code authors could’ve thought of all legitimate/sensible uses ahead of time. But good engineers tend to decompose code into smaller classes and functions, which often have a pretty good chance of being extended rather safely in practice.
It is wild but such is the consequence of the culture that punishes explicit failure, and ignores failure to be able to ship fixes for the unpredicted situation and ignores failure to have a productive code base. I cry for the mounds of copy-pasted code that must result from this policy that treats its engineers code like radioactive garbage.
Exception: final parameters. They should never be assignable.
I mostly agree with you, but Spring+Kotlin does require the allopen plugin, so it's kind of hacking Kotlin to do the wrong thing (all classes open) in order to support an arguably bad design choice by Spring.