Hi, I have a feature request I think that the int...

# konsist

[buszi0809]

Hi, I have a feature request

I think that the interfaces you've created for classes and objects have their pros and cons. And I think I've found a huge issue with that.

I have a case where a teammate wanted to verify that declarations of routes in the new Jetpack Navigation Compose approach have correct declarations. For example you have such a sealed interface:

interface Route

sealed interface AuthRoute : Route {
   @Serializable
   data object Home : AuthRoute

   @Serializable
   data class User... : AuthRoute
}

And here I'd like to verify that classes and objects that implement Route have Serializable annotation and data modifier.

Unfortunately, I can't perform something like Konsist.scopeFromProject().classesAndObjects() and when I perform classes() + objects() the compiler will result in the first common type, which is the base type. Because of that I can't perform f.e
.withParentOf(Route::class).

That's because the structure of those interfaces (KoClassDeclaration and KoObjectDeclaration) is that they implement really granular interfaces, and don't have common base interfaces to share functionalities.

I think it could be improved, and for such cases we should be able to sum those values and perform operations on interfaces that they have in common.

[igor.wojda]

Thx for raising this. We are aware of this behaviour. TBH I don't se and ideal way of modeling this using Kotlin type system., so we are considering addition of classesAndObjects() like methods as a workaround.

For this simple case you can also use an alternative way of filtering declarations by using providers (representing a certain aspect/type). This check is still limited to a single type but allows to cross this class/interface/object boundary.

Konsist
    .scopeFromProduction()
    .declarationsOf<KoAnnotationProvider>
    .assertTrue { 
        // it is of type KoAnnotationProvider
        it.hasAllAnnotationsOf(Serializable::class) 
    }

[igor.wojda]

BTW the feature that would be helpful in Kotlin to support this are Intersection Types https://docs.scala-lang.org/scala3/reference/new-types/intersection-types.html.

Before going with classesAndObjects we have to do some spike, as perhaps there may be some Intersection Types alternatives for Kotlin