m

    molikto

    2 years ago
    Is there a way to mark a parameter of type
    List<String>
    as stable?
    Adam Powell

    Adam Powell

    2 years ago
    it's not stable though 🙂
    l

    Leland Richardson [G]

    2 years ago
    the short answer is “no, not really”. But can I ask you to elaborate more on why you want to? I’m curious about how this type of thing manifests in the wild and would like to understand it more
    in the future, for instance, it might be possible for us to infer certain patterns as stable (for instance,
    listOf("foo", "bar")
    but right now we can’t do that safely for a variety of reasons
    Adam Powell

    Adam Powell

    2 years ago
    ModelList
    might be a solution here, depending
    but I assume we don't have a readonly interface type for it (yet?)
    l

    Leland Richardson [G]

    2 years ago
    no. List is read-only but not stable but we figured that would be good enough
    but i don’t think that List<String> being stable should be a requirement for correctness
    m

    molikto

    2 years ago
    I don't really have a valid case for this, except for my desire that more calls be cached, but in practice there might not be any performance difference (or there are cases it is worse performnace?).
    l

    Leland Richardson [G]

    2 years ago
    it can go either way but if there’s a chance for all parameters to compare true with previous versions, then generally it will be a performance win
    but my recommendation to you would be to not worry about it until it is an actual problem
    for instance if you’re passing these strings into some other composable somewhere, Strings are stable and then you might get some good skipping happening at those call sites
    in the long run we want to gradually make things smarter so that this can happen a higher percentage of the time
    but we would like for it to be something that you just don’t really need to worry about in most cases
    m

    molikto

    2 years ago
    Agreed, I think most of time it doesn't mater that much, because all the heavy-lifting happens inside widget-API
    If it really matters, one can always use a wrapping Stable class... so I guess I am just nitpicking
    l

    Leland Richardson [G]

    2 years ago
    yeah especially as we improve performance more and more, my hope is that we can just recommend to not worry about this in user-land. You’re right that the heavy lifting happens below widget-level APIs in most cases. That said, there will no doubt be cases where this does make or break whether a certain API in user-land is sensible, and we are definitely trying to think about the right way to tackle this problem
    i really don’t want to see
    @Stable
    annotation sprinkled over almost every type in user-land though
    ideally kotlin at some point can provide some notion of immutability that we can rely on from a more language-level ecosystem standpoint
    m

    molikto

    2 years ago
    thanks!
    Zach Klippenstein (he/him) [MOD]

    Zach Klippenstein (he/him) [MOD]

    2 years ago
    ideally kotlin at some point can provide some notion of immutability that we can rely on from a more language-level ecosystem standpoint
    This would be awesome, but this seems very unlikely anytime soon. It would probably require a better notion of immutability on the JVM or value types or something wouldn’t it? I haven’t been following the progress of Valhalla too closely but I would think it’s quite a ways off for android use.
    l

    Leland Richardson [G]

    2 years ago
    correct, for some definition of “soon” lol
    there’s a lot of different avenues here, but basically i want us to be cautious about creating a world where
    @Stable
    is sprinkled all around the entire ecosystem
    at least without thinking carefully about it first