Thanks. I had the good fortune of reading through that after watching a couple Jetpack Compose videos, and now I feel it clicks - seems like your "topo" is very similar to @Composable.
-
-
yeah, leland and i have been nerd sniping each other for a while too
1 reply 0 retweets 1 like -
Replying to @__anp__ @raphlinus and
the key difference there comes down to the use of hashable ids in topo (and absence of a compiler plugin) vs a structural approach based on the layout of the composition buffer iiuc
1 reply 0 retweets 1 like -
Replying to @__anp__ @raphlinus and
what bad form to not ping
@intelligibabble1 reply 0 retweets 1 like -
Clearly the compiler plugin makes a huge difference for ergonomics, so interesting to see what can be done in Rust space. Very clever callsite id using ordinary macros, and proc macros might do even more, though I see it's tricky.
1 reply 0 retweets 1 like -
Replying to @raphlinus @jckarter and
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.
1 reply 0 retweets 1 like -
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.
-
-
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 - 10 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.