mcpiroman
08/04/2022, 5:48 PM@Volatile
) so there could be a meta annotation `@External`that only enables that annotations to be used externally.ephemient
08/04/2022, 6:07 PMmcpiroman
08/08/2022, 8:07 AMephemient
08/08/2022, 12:18 PM@Serializable
- it would have to modify the original classes@Stable
and @Immutable
too - the presence of the annotation isn't the important part, it's what the compiler plugin does with the annotation during compilation of that class that matters. adding the annotation afterwards does nothingmcpiroman
08/09/2022, 8:06 AMDave
08/09/2022, 8:24 AMephemient
08/09/2022, 2:57 PMmcpiroman
08/10/2022, 8:29 AM@Inferred
annotation and/or a static field. So it may not work OOTB (although it could). What I meant is that when adding such a feature, to flag external declarations, to compose, it would likely be easier and more consistent to the user (while not much harder for developers) to use external annotations, rather than passing a list of class names in gradle config, or how else it needs to be solved otherwise.Dave
08/10/2022, 8:32 AMephemient
08/10/2022, 3:14 PMmcpiroman
08/11/2022, 9:42 AMYou may not have access to the classes in order to annotate them.You mean a situation when a class is in the runtime, but not compiler classpath? So all my examples are concerned with annotating declarations that you actually use (that are visible by compiler); I assume that's the vast majority of use cases. Otherwise it is messing with internals. And it would not even work because external annotations only change how the compiler sees other declarations when compiling current module. But maybe you have some practical example, either with compose or anything else, when it's sensible to do so? Because then it actually could be made possible to annotate invisible external class by full name, perhaps with suppressible warning.
Besides you shouldn't annotate with stuff that is about how the class is used. Upside down dependency!!!And how are external annotations worse when other approaches, e.g. list of classes for compose, xml with (non)nullables for java declarations, or `@Serializer(forClass = lib.Foo::class)`annotation in kotlinx.serialization? They all declare such a dependency, just with different syntax. Or perhaps all such attempts are tainted. May be, but then how would you advice go around their needs? For example: there is a `kotlinx.collections.immutable.ImmutableCollection`that we know is strictly immutable and want to benefit from this fact in a Compose application. But currently Compose compiler does not know anything about it. So we could: • Annotate `ImmutableCollection`at its source with
@Stable
. That would create a dependency of kotlinx.collections.immutable
on compose runtime. And maybe its feasible there, as both libraries are 'kotlin official', but it would not be possible to do for all other libraries, say pcollections.
• Add a special case for ImmutableCollection
in compose compiler. That would create an informal dependency on kotlinx.collections.immutable
. But like above, it's not possible to write down a list of all possible libraries someone would like to use alongside Compose.
• So here we are, what's left is to declare a dependency between those two libraries at the use side. Maybe it's not that clean, but IMHO still better than the two possible dependencies above.