From the language perspective and idiomatic Kotlin...

# compose

[orangy]

From the language perspective and idiomatic Kotlin, it would be nice to have a sketch on how could a generic system look like, even if still a plugin. By generic, I mean something that is not bound to this UI system, nor to Android or anything else. Like it was said on suspend function, let’s imagine for a moment we are doing an “incremental structure updates” plugin to the language, and let’s pretend we can have a (soft) keyword. In the true Kotlin spirit, we should be able to develop libraries and frameworks, and not just UIs. Like if we have compose fun Data(name: String), then where the composition context comes from, how do you scope different DSLs belonging to different systems, etc. These are open questions, and they are probably out of scope of this very specific use case, but I find it interesting thinking about it and it would be nice to see what you folks think here.

[napperley]

Also the compose concept would need to retain most of the advantages of the receiver concept (explicit context, readable free form context initialisation in code block, function parameters optional etc).

[miha-x64]

Yes! There's no need for a keyword/annotation, you just take a receiver and patch its contents.

[orangy]

The topic on receiver was explained very well by @Leland Richardson [G]

[napperley]

Even so it would be a huge shame to not make feasible improvements to the Receiver concept, which is very relevant even though it has its downsides (as mentioned by @Leland Richardson [G]) like every other concept, and still has its place where it is a good fit for solving some problems.

[Leland Richardson [G]]

agreed - would still love to see our proposal for receivers to get accepted (or something that solves the same problems)

[napperley]

Would be good to see the proposal taking the best bits from both approaches (Receiver and Function call) 😄.

[napperley]

One important condition for the proposal is that it leans heavily towards explicit development (emphasis on readability, easy troubleshooting, and testability), and completely removes the need to use annotations/compiler plugins.

[Leland Richardson [G]]

the proposal i was referring to was just an addition to kotlin allowing for the specification of multiple/combined receiver scopes on a function, instead of limiting to one

[Leland Richardson [G]]

even if this proposal got accepted though, i am pretty confident that compose would not move to utilizing receiver scopes to thread the composer through

[Leland Richardson [G]]

but regardless of that, i think it still might be a good addition to the language