4 ms·

Where can I go to suggest new "recipes"? I see that it starts with random numbers, but when I was learning I got tripped up a bit when trying to generate seede

Where can I go to suggest new "recipes"? I see that it starts with random numbers, but when I was learning I got tripped up a bit when trying to generate seeded randoms.

steveklabnik 8y ago
The little “edit” button at the top takes you to the github repo, filing an issue is the way to go. It might take some time to respond to, because this project got really far but not quite across the finish line, and I think the main maintainer has dropped out. We’ll get to it...
amelius 8y ago
I'd like to see an official recipe for using closures as callbacks (for example in a UI library), where variables in outer scopes are potentially modified from within the closure. See e.g. [1] for a possible approach. [1] https://gtk-rs.org/docs-src/tutorial/closures https://gtk-rs.org/docs-src/tutorial/closures
- steveklabnik 8y ago
  I’m a bit torn about this one, because it’s not universally clear that this is the correct way to build these kinds of systems in Rust. GTK has to due to the constraints of the system it binds to, but there’s a lot of experimentation of different ways that may be more Rust-y and not have the huge pain points this approach has. Once its sorted, I think comparing and contrasting this kind of thing would be amazing though.
  - amelius 8y ago
    What would be an alternative, equally flexible way to handle callbacks?
    - steveklabnik 8y ago
      https://raphlinus.github.io/personal/2018/05/08/ecs-ui.html https://raphlinus.github.io/personal/2018/05/08/ecs-ui.html is an entry point into the main alternative that’s being explored, see “druid” as a package that’s an implementation of (an evolution of) these ideas, though it’s still early days. In general, Rust hates big balls of intertwined mutable state. And traditional OOP-y UI frameworks are basically giant balls of intertwined mutable state. You can do it, but it’s not great. We’ll see.
      - int_19h 8y ago
        Realistically, this is still a necessity, because even if Rust comes up with its own quality UI frameworks - which takes years, looking at the history of the ones that we have - some people will still need to integrate with what's already there.
        steveklabnik 8y ago
        Sure, it's still necessary, but that doesn't mean that it needs to be promoted as the correct pattern to use in the general case.

Where can I go to suggest new "recipes"? I see that it starts with random numbers, but when I was learning I got tripped up a bit when trying to generate seeded randoms.

steveklabnik 8y ago

The little “edit” button at the top takes you to the github repo, filing an issue is the way to go. It might take some time to respond to, because this project got really far but not quite across the finish line, and I think the main maintainer has dropped out. We’ll get to it...

amelius 8y ago

I'd like to see an official recipe for using closures as callbacks (for example in a UI library), where variables in outer scopes are potentially modified from within the closure. See e.g. [1] for a possible approach. [1] https://gtk-rs.org/docs-src/tutorial/closures https://gtk-rs.org/docs-src/tutorial/closures

steveklabnik 8y ago
I’m a bit torn about this one, because it’s not universally clear that this is the correct way to build these kinds of systems in Rust. GTK has to due to the constraints of the system it binds to, but there’s a lot of experimentation of different ways that may be more Rust-y and not have the huge pain points this approach has. Once its sorted, I think comparing and contrasting this kind of thing would be amazing though.
- amelius 8y ago
  What would be an alternative, equally flexible way to handle callbacks?
  - steveklabnik 8y ago
    https://raphlinus.github.io/personal/2018/05/08/ecs-ui.html https://raphlinus.github.io/personal/2018/05/08/ecs-ui.html is an entry point into the main alternative that’s being explored, see “druid” as a package that’s an implementation of (an evolution of) these ideas, though it’s still early days. In general, Rust hates big balls of intertwined mutable state. And traditional OOP-y UI frameworks are basically giant balls of intertwined mutable state. You can do it, but it’s not great. We’ll see.
    - int_19h 8y ago
      Realistically, this is still a necessity, because even if Rust comes up with its own quality UI frameworks - which takes years, looking at the history of the ones that we have - some people will still need to integrate with what's already there.
      - steveklabnik 8y ago
        Sure, it's still necessary, but that doesn't mean that it needs to be promoted as the correct pattern to use in the general case.