Enabling Inheritance on Poet Classes & Builders

[brizzbuzz]

Wanted to gauge community interest in allowing KotlinPoet class declarations to be extended. By default Kotlin classes are private, so this would mostly just require adding the open modifier to most classes.

The reason being, there are certain things that developers may want to build (in my case, certain DSL streamline functions) that most likely don't really belong in the KotlinPoet repo. Opening up these classes would allow external extension that is currently not feasible.

Curious to hear if there are any arguments against allowing this feature.

[ZacSweers]

Isn't this what extension functions are for?

[ZacSweers]

What you want is multiple receivers on extension functions, which is being explored here: https://youtrack.jetbrains.com/issue/KT-10468

I don't think your use case alone is a compelling enough reason to make these classes open.

[brizzbuzz]

I disagree, it's not so much one compelling use case or another, but rather that leaving them closed prevents other users from leveraging KotlinPoet in the way they choose.

So rather than assessing this one use case, I would ask what the gain is of leaving them final.

[brizzbuzz]

Side note, I'm not holding out hope for multiple receivers any time soon it's been a tracked issue for over half a decade

[ZacSweers]

Sorry you'll need to take no for an answer here. Inheritance must be designed for, open by default is an anti-pattern and there's a reason kotlin is closed by default. The question is always why, not why not.

[Egorand]

+1, these classes haven't been designed to be open, if we just make them open we'll likely run into bugs we won't want to fix. And there's no going back too, so unless there's a very very compelling case to have them be open, we won't consider this. What you're running into does feel like a language limitation, and not an issue with how the library is designed.