indeed! i've been making progress on implementing https://github.com/rust-lang/rust/issues/47809 …, which i'm fairly confident will let me eliminate the macros from topo. down to a couple of llvm errors and i should be able to prototype it.
-
-
Replying to @__anp__ @raphlinus and
even with that, the main win of the compiler plugin iiuc is static typing for the implicitly propagated composer type, so you can e.g. determine whether you're in an android or skia context and fail compile if you emit the wrong nodes
2 replies 0 retweets 0 likes -
Doesn't it also transform plain struct.field access into a subscribe to an observable object? That seems to me one of the main magics people now expect from declarative UI.
1 reply 0 retweets 0 likes -
Replying to @raphlinus @jckarter and
ah i'm out of date, they used to have a sigil for that
1 reply 0 retweets 0 likes -
Replying to @__anp__ @raphlinus and
and yeah magic field access seems unlikely to come to rust...ever? :(
1 reply 0 retweets 0 likes -
I'm not convinced it should. In druid it's plain old field access within closures etc, but then it's lenses at composition boundaries. I think there's a good argument this is the Right Way in Rust, and doesn't require lang magic.
1 reply 0 retweets 1 like -
Replying to @raphlinus @jckarter and
yeah i think it would wreck rust, fwiw. for moxie's state keys, you could implement special binding behavior on Deref? but as it is the whole runtime is woken up on state changes and memoization equality checks are how i avoid excessive work, no need to bind on reads
1 reply 0 retweets 0 likes -
Replying to @__anp__ @raphlinus and
or rather, the state variable is bound-on-acquisition, and its assumed that functions you call will be re-run as needed if they receive some sub-field of that value
1 reply 0 retweets 0 likes -
Replying to @__anp__ @raphlinus and
There's a high bar to reach for compiler level plugin. It was/is a gamble, but makes sense for us I think. Once you have it, lots of potential to improve ergonomics though.
1 reply 0 retweets 1 like -
Replying to @intelligibabble @raphlinus and
I'm not certain that the implicit observation of
@Model was the right call or not, but it does have a lot of advantages. That said, yeah - might not make sense in the context of rust. Swift UI made similar judgement calls i suppose.4 replies 0 retweets 1 like
Rust makes things interesting in lots of ways. Thing is, we can evolve the language if need be, but I think we need a *really* good story of what that should be and why we need it. I personally don't feel like I understand the domain well enough yet. JC is inspiration here.
-
-
Replying to @raphlinus @jckarter and
Yeah. I am trying to look at JC through the lens of "what is specific to Android + UI, and what can be more general as a language feature". What is exciting is that as time has gone on we have been able to simplify what
@Composable actually means to us more and more1 reply 0 retweets 1 like -
Replying to @intelligibabble @raphlinus and
The best parallel IMO is with async/await. Several languages have now adopted this type of feature. I *think* as we iterate on things, it will become more clear what a composable function is / what it's useful for, and we can formalize it.
1 reply 0 retweets 1 like - 5 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.