Destionation annotation & interface name clash

[hrach]

Currently the Destination's annotation and interface name are same and fqn/import alias has to be used.
This is quite inconvenient. It would be great if one of them get renamed.

Second, it seems that KSP won't pickup an import-aliased Destination annotation.

[raamcosta]

Hi @hrach 👋
Thanks for the feedback!

I understand, but at the same time I kind of like that a Destination annotation generates a Destination.
What I found is that it should be rare that you want to import both of them in the same file.
What is your use case for wanting to import both in the same file?

I'm definitely not excluding the possibility of renaming the interface. It's just that I'd like to know exactly the cases where we'd want to import both of them before I make a decision.

[raamcosta]

Btw, this might be a good solution in the meantime:

typealias AppDestination = com.ramcosta.composedestinations.Destination

Put this anywhere and then you can refer to the Destination interface as AppDestination.

[hrach]

My use case is the main screen (also a destination) has many navigables to other screens and so I have them created separately as a list and passing them around - then I need to type them.

I kind of like that a Destination annotation generates a Destination

I'd say it can also bring some confusion. We are marking a composable as a destination, but the generated resulting object is much more than a "destination", it is a routing specs, argument processor, navigation factory... Since this interface is used much less than the annotation I'd change its name. Surprisingly, I've just realized the interface is already named correctly - DestinationSpec. It seems quite right to me.

Knowing this it seems to be solved for me as I don't utilize the sealed interface.

[raamcosta]

Yap, in the core, the interface is DestinationSpec. The only reason we have Destination generated is so that it can be sealed. I think it allows for some neat extension functions/properties.

I think with both solutions described here typealias and just using DestinationSpec, we can close this issue for now, if you agree. Later if this comes up again, I'll rethink the name of the generated one.

Please close it if you agree 🙂