# compose

Michal Bacik

10/29/2019, 8:24 PM
Thought on internals: I see that during composition, there is static variable
used; this is probably referenced by the Compose plugin as it transforms @Composable functions. (global variables are evil 😉 ) Wouldn't it be better to omit magic code transformations, and follow style of Kotlin coroutines which are implemented purely as library (except of compiler
keyword)? Coroutine builders pass
as receiver parameter to body of couroutine, and there is no hidden magic behind this, we can study all state of coroutine in debugger. Instead of global
variable, Compose would work on a composer build state as normal reveicer variable into
function . Do Compose designers fear that developers would mess with the build state and make more mistakes, or want hide implementation, or what's purpose of this rather complicated implementation wich needs special plugin and reworked Kotlin compiler?
Thanks, that makes sense. Hope one day we can learn in a video or blog what kind of tranforms are done to
marked functions, for now it looks like black magic 🙂 Kotlin developers explained in one video what's behind scenes of their coroutines, since then I understood it. Maybe one day you can make similar explanation video what truly happens with the code of
funcs (e.g. there's invisible injected builder, or such).


10/29/2019, 8:49 PM
Hi @Michal Bacik, I want to recommend this talk on Android Dev Summit 2019 if you haven't seen it yet


Michal Bacik

10/29/2019, 8:50 PM
Thanks, I'll have a look.
Also found this good post: thanks @Leland Richardson [G]!


10/29/2019, 10:29 PM
The talk by Leland answers most of your questions really well

Leland Richardson [G]

10/29/2019, 11:21 PM
note that my talk is given as if this currentComposer global var doesn’t exist… because it won’t for long. it was always seen as a “temporary solution”, where threading the composer through as a parameter was the intent. getting the compiler to work like we want in this case is not a small amount of work
👍 1