https://kotlinlang.org logo
#language-evolution
Title
# language-evolution
e

eygraber

02/22/2024, 4:42 PM
Any thoughts on having an annotation that could be applied to abstract functions or properties that would force an immediate child to implement it? The use case is that I have a hierarchy of abstract classes and don't control the final concrete class, but I want to ensure that one of the abstract classes in the hierarchy will implement the abstract function or property.
c

CLOVIS

02/23/2024, 3:43 PM
Why do you want to do this?
e

eygraber

02/23/2024, 4:07 PM
I'm building a framework that uses https://github.com/evant/kotlin-inject and I provide an
abstract class
that the user will extend from another
abstract class
(kotlin-inject will generate the concrete class with KSP). The intermediate abstract class needs to implement an abstract property, because KSP isn't able to generate it.
c

CLOVIS

02/23/2024, 4:11 PM
In my opinion, if this is a problem caused by code generation, then it's out of scope for a language evolution. Code generation is side-stepping what the language allows, so the language shouldn't adapt to use cases that stem from that. Instead, I would create a feature request to KSP or elsewhere. (of course, I'm not the one who makes the rules, but I think it's unlikely this leads to anything)
e

eygraber

02/23/2024, 4:15 PM
This isn't caused by code generation; my specific use case involves code generation, but the underlying issue is still there. Another example would be a library providing an abstract class meant to be extended by an abstract class from another library. There's the same lack of control of implementation.
c

CLOVIS

02/23/2024, 4:20 PM
Yes, but I believe it's on purpose. Abstract classes define classes "with holes" that implementations need to fill in. An abstract class cannot force an implementation to be of a specific kind; you can always implement them as
object
,
class
, anonymous objects, etc. The implementation has entire control over this. Your use case is an abstract class that wants to force its implementation to 1) be an abstract class, and 2; implement a subset of its methods. I do not think this aligns with the language's goals, however it could maybe be a #detekt rule or something similar? Or just a different design that doesn't require something like this at all.
e

eygraber

02/23/2024, 4:56 PM
It wouldn't force the implementation to be an abstract class, just that if it is an abstract class, it has to implement the annotated properties/functions. It also doesn't force what the implementation is, but that the direct child provides an implementation. This isn't such a large leap, because currently: 1. If the child of an abstract class is a concrete class, it must provide an implementation 2. If the child of an abstract class is an abstract class, it may provide an implementation I'm just asking for a way to bridge that. I don't think there's a way for static analysis to address this, since it would suppose that a consumer (which is not under your control) would be using static analysis.