3 ms·

By opaque, do you mean encapsulated? Encapsulation is pretty important to software architecture, in that it enforces decoupling between components. Rust has pri

By opaque, do you mean encapsulated? Encapsulation is pretty important to software architecture, in that it enforces decoupling between components. Rust has private visibility for this very reason. The filtering you're talking about sounds interesting, but the GUI layer is (imo) definitely the wrong place to do it. When's the last time you wanted to filter, prioritize, secure, or distribute UI events? Imagine if we transformed every method call in our app into enums, it would be an unwieldy and unreadable mess. I'm not saying you're suggesting that, just highlighting that there are definitely some drawbacks here. So, I don't see why we're being forced to use enums in this case. I wonder if this a conscious decision by the Iced folks, and if they first tried with closures and ran into some trouble. Your hybrid idea is interesting! Is that doable with Rust in practice? I'd imagine the borrow checker might enforce it can't read from outside its scope.

jerf 5y ago
"By opaque, do you mean encapsulated?" By opaque, I mean the only thing you can do is execute them. While this is encapsulated, it isn't at the right level of control. " but the GUI layer is (imo) definitely the wrong place to do it. When's the last time you wanted to filter, prioritize, secure, or distribute UI events?" Ironically, the GUI is already that way. Under the hood, enumerated values were passed to your program by the windowing system. It has to be, because there's a serialization layer there. GUI programs already have no choice but to be structured this way, and indeed, also certainly have some sort of filtering mechanism in them to do things like ignore events it doesn't want to handle. You're probably programming at an abstraction layer that is already sitting above that. You think this isn't useful in a GUI precisely because the GUI framework you're using implemented this pattern for you already! "Your hybrid idea is interesting! Is that doable with Rust in practice?" Really it's just creating objects that have various inspectable attributes as needed, that also have some trait or something that allows them to be called in a uniform manner. It's not too hard, it's just a bit more structure around what is already there; you basically copy & paste the closure into the method of a new object, and make the capture explicit in the object.

jerf 5y ago

"By opaque, do you mean encapsulated?" By opaque, I mean the only thing you can do is execute them. While this is encapsulated, it isn't at the right level of control. " but the GUI layer is (imo) definitely the wrong place to do it. When's the last time you wanted to filter, prioritize, secure, or distribute UI events?" Ironically, the GUI is already that way. Under the hood, enumerated values were passed to your program by the windowing system. It has to be, because there's a serialization layer there. GUI programs already have no choice but to be structured this way, and indeed, also certainly have some sort of filtering mechanism in them to do things like ignore events it doesn't want to handle. You're probably programming at an abstraction layer that is already sitting above that. You think this isn't useful in a GUI precisely because the GUI framework you're using implemented this pattern for you already! "Your hybrid idea is interesting! Is that doable with Rust in practice?" Really it's just creating objects that have various inspectable attributes as needed, that also have some trait or something that allows them to be called in a uniform manner. It's not too hard, it's just a bit more structure around what is already there; you basically copy & paste the closure into the method of a new object, and make the capture explicit in the object.