orangy

    orangy

    3 years ago
    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.
    n

    napperley

    3 years ago
    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

    miha-x64

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

    orangy

    3 years ago
    The topic on receiver was explained very well by @Leland Richardson [G]
    n

    napperley

    3 years ago
    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.
    l

    Leland Richardson [G]

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

    napperley

    3 years ago
    Would be good to see the proposal taking the best bits from both approaches (Receiver and Function call) 😄.
    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.
    l

    Leland Richardson [G]

    3 years ago
    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
    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
    but regardless of that, i think it still might be a good addition to the language