Replies: 1 comment 8 replies
-
|
Isn't this what extension functions are for? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
+1, these classes haven't been designed to be open, if we just make them |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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
openmodifier 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.
Beta Was this translation helpful? Give feedback.
All reactions