8 ms·

Forgive my ignorance of Rust, but GUI toolkits are probably the strongest candidate for OOP style development, and everything I've read about Rust doesn't lend

Forgive my ignorance of Rust, but GUI toolkits are probably the strongest candidate for OOP style development, and everything I've read about Rust doesn't lend itself well to OOP. StyledObject -> View -> Text StyledObject -> View -> ViewContainer -> Button -> ToggleButton -> MyCustomToggleButton StyledObject -> View -> ViewContainer -> VerticalLayout -> ListView

coldtea 6y ago
>Forgive my ignorance of Rust, but GUI toolkits are probably the strongest candidate for OOP style development That's so 1991. We're on to GUI's as pure functions of state these days, get on with the program :-)
- BlueTemplar 6y ago
  Tell us more ?
  - k__ 6y ago
    Cycle.js, Callbags, etc.
  - deleted 6y ago
    [deleted]
  - coldtea 6y ago
    Elm and React for one... and all the other similarly inspired UI libs (even SwiftUI is kind of going there)... Plus the increased interested on fp UIs for games, entity systems, etc... https://www.freecodecamp.org/news/the-revolution-of-pure-views-aed339db7da4/ https://www.freecodecamp.org/news/the-revolution-of-pure-vie...
  - 3PS 6y ago
    Check out these articles surveying the landscape of reactive UI, from the same author as the linked article: https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui.html https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui.... https://raphlinus.github.io/rust/druid/2020/09/25/principled-reactive-ui.html https://raphlinus.github.io/rust/druid/2020/09/25/principled...
- seanalltogether 6y ago
  I'm not entirely convinced. Libraries like React have succeeded in web development due to the complete lack of html having an extensible component model. Native applications don't have to worry about shoehorning a workable framework into stateless document renderers.
  - realharo 6y ago
    No, this is a larger trend. Both major mobile platforms are moving in this direction as well (SwiftUI, Jetpack Compose).
- andrewmcwatters 6y ago
  There's really no such thing. You might be using pure functions from your perspective, but someone is handling all that backing layer data and mutable information.
  - lmm 6y ago
    There's no such thing as structured programming, at the assembly level it always just compiles down to conditional jumps. There's no such thing as a digital circuit, because real-world voltages are always analogue. Etc.
    - oblio 6y ago
      Yeah, but some abstractions are leakier than others. I have never hit a real-world voltage bug or conditional jump bug, as far as I remember.
      - lmm 6y ago
        Have you ever hit a bug in the implementation of immutable data? I haven't. (And I have seen a miscompiled loop, though I agree they're very rare).
        oblio 6y ago
        Well, now that I think about it, I have seen a compiler bug in an IBM Java compiler where an if condition would never be hit, despite the code being fine and the Sun Java compiler working as expected.
    - andrewmcwatters 6y ago
      Which is all dealing with retained, mutable data. Period. I'm not making the comment for the sake of pointing out _levels_ of abstraction. I made the comment because such an abstraction doesn't at all map to reality.
      - lmm 6y ago
adamnemecek 6y ago
GUI toolkits have been written in the OOP style since it's the paradigm available. If SML had become popular, I'm sure we'd be writing that.
- monocasa 6y ago
  ML is from almost exactly the same time period as SmallTalk and it's work creating GUIs.
  - adamnemecek 6y ago
    I'm well aware, what's your point.
    - monocasa 6y ago
      The paradigms have been available for pretty much exactly the same amount of time, down to the year.
      - adamnemecek 6y ago
        I'm aware. What's your point?
  - wtetzner 6y ago
    The point was that OOP was popular, ML wasn't.
    - monocasa 6y ago
      ML was pretty popular in the day. But my point is that it's pretty weird to bring up SML in particular around GUI programming. The GUI framework only example I know of is mGTK and SML/tk which are far from idiomatic and pretty much require you to write imperative OOP code in SML. Meanwhile SML has existed for decades. It's one thing to say "people aren't using this great model we've developed the basics off, please help make it better", but if you wanted to write an idiomatic GUI app in SML today, your first step would be to have to write the GUI framework itself because no one else has. They don't provide any real options even if you fully buy in and want to jump in with what they're saying.
ecshafer 6y ago
But rust does have Traits which work perfectly fine for that same logic. We can just say this trait implements the Button and ToggleButton Traits.
- jcelerier 6y ago
  > But rust does have Traits which work perfectly fine for that same logic. We can just say this trait implements the Button and ToggleButton Traits. i've never seen that not being called oop
  - ragnese 6y ago
    It pretty much is. But it's not exactly class inheritance, so most people don't consider Rust to be OOP. Structs ("classes" in Rust) can implement Traits and Traits can "inherit" each other, but structs can't inherit implementations from other structs.
    - jcelerier 6y ago
      > Structs ("classes" in Rust) can implement Traits and Traits can "inherit" each other, but structs can't inherit implementations from other structs. Right, this is textbook interfaces used for composition. Let me paste you a few paragraphs from the GoF book, released in 1994: > Inheritance versus Composition > The two most common techniques for reusing functionality in object-oriented systems are class inheritance and object composition. As we've explained, class inheritance lets you define the implementation of one class in terms of another's. Reuse by subclassing is often referred to as white-box reuse. The term "white-box" refers to visibility: With inheritance, the internals of parent classes are often visible to subclasses. > Object composition is an alternative to class inheritance. Here, new functionality is obtained by assembling or composing objects to get more complex functionality. Object composition requires that the objects being composed have well-defined interfaces. This style of reuse is called black-box reuse, because no internal details of objects are visible. Objects appear only as "black boxes." ... > Object composition has another effect on system design. Favoring object composition over class inheritance helps you keep each class encapsulated and focused on one task. Your classes and class hierarchies will remain small and will be less likely to grow into unmanageable monsters. On the other hand, a design based on object composition will have more objects (if fewer classes), and the system's behavior will depend on their interrelationships instead of being defined in one class. Like, it's the most well-known OOP design book and it states exactly that - more than a QUARTER CENTURY ago. Who in hell argues that this isn't oop ?!
anchpop 6y ago
React is a very popular GUI toolkit and it doesn't use OOP functionality at all.
- andrewmcwatters 6y ago
  React isn't the one doing the actual drawing.
- Const-me 6y ago
  https://reactjs.org/ https://reactjs.org/ says right on the front page: "Build encapsulated components that manage their own state, then compose them to make complex UIs." Components managing their own state is a textbook definition of OOP.
  - wtetzner 6y ago
    Encapsulation is not equivalent to OOP. If it is, then why do we have two separate terms for the same thing?
simias 6y ago
That's one way to do it, but you could have something very similar that uses composition instead of inheritance (and a nice trait hierarchy to top it off). MyCustomToggleButton would contain an instance of ToggleButton and override some behavior while implementing ToggleButtonInterface or whatever. I don't know if that's the way to go but that'd work.
still_grokking 6y ago
As every "flat" hierarchy this is inflexible and impossible to get right (think "ComboBox" or "MenuButton" for example). A better approach are mixins. Separate ones for layout and behavior. This is much more flexible, and avoids code duplication or "crazy" inheritance hierarchies at the same time. Rust Traits are ideal for mixins. So a GUI toolkit in Rust should be just fine.
- jcelerier 6y ago
  > As every "flat" hierarchy this is inflexible and impossible to get right (think "ComboBox" or "MenuButton" for example). why does it work fine in Qt then ?
  - rcxdude 6y ago
    It doesn't work super well. It functions, but there's all kinds of funky interface design which basically exists because of the nature of inheritance.

coldtea 6y ago

>Forgive my ignorance of Rust, but GUI toolkits are probably the strongest candidate for OOP style development That's so 1991. We're on to GUI's as pure functions of state these days, get on with the program :-)

BlueTemplar 6y ago
Tell us more ?
- k__ 6y ago
  Cycle.js, Callbags, etc.
- deleted 6y ago
  [deleted]
- coldtea 6y ago
  Elm and React for one... and all the other similarly inspired UI libs (even SwiftUI is kind of going there)... Plus the increased interested on fp UIs for games, entity systems, etc... https://www.freecodecamp.org/news/the-revolution-of-pure-views-aed339db7da4/ https://www.freecodecamp.org/news/the-revolution-of-pure-vie...
- 3PS 6y ago
  Check out these articles surveying the landscape of reactive UI, from the same author as the linked article: https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui.html https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui.... https://raphlinus.github.io/rust/druid/2020/09/25/principled-reactive-ui.html https://raphlinus.github.io/rust/druid/2020/09/25/principled...
seanalltogether 6y ago
I'm not entirely convinced. Libraries like React have succeeded in web development due to the complete lack of html having an extensible component model. Native applications don't have to worry about shoehorning a workable framework into stateless document renderers.
- realharo 6y ago
  No, this is a larger trend. Both major mobile platforms are moving in this direction as well (SwiftUI, Jetpack Compose).
andrewmcwatters 6y ago
There's really no such thing. You might be using pure functions from your perspective, but someone is handling all that backing layer data and mutable information.
- lmm 6y ago
  There's no such thing as structured programming, at the assembly level it always just compiles down to conditional jumps. There's no such thing as a digital circuit, because real-world voltages are always analogue. Etc.
  - oblio 6y ago
    Yeah, but some abstractions are leakier than others. I have never hit a real-world voltage bug or conditional jump bug, as far as I remember.
    - lmm 6y ago
      Have you ever hit a bug in the implementation of immutable data? I haven't. (And I have seen a miscompiled loop, though I agree they're very rare).
      - oblio 6y ago
        Well, now that I think about it, I have seen a compiler bug in an IBM Java compiler where an if condition would never be hit, despite the code being fine and the Sun Java compiler working as expected.
  - andrewmcwatters 6y ago
    Which is all dealing with retained, mutable data. Period. I'm not making the comment for the sake of pointing out _levels_ of abstraction. I made the comment because such an abstraction doesn't at all map to reality.
    - lmm 6y ago

adamnemecek 6y ago

GUI toolkits have been written in the OOP style since it's the paradigm available. If SML had become popular, I'm sure we'd be writing that.

monocasa 6y ago
ML is from almost exactly the same time period as SmallTalk and it's work creating GUIs.
- adamnemecek 6y ago
  I'm well aware, what's your point.
  - monocasa 6y ago
    The paradigms have been available for pretty much exactly the same amount of time, down to the year.
    - adamnemecek 6y ago
      I'm aware. What's your point?
- wtetzner 6y ago
  The point was that OOP was popular, ML wasn't.
  - monocasa 6y ago
    ML was pretty popular in the day. But my point is that it's pretty weird to bring up SML in particular around GUI programming. The GUI framework only example I know of is mGTK and SML/tk which are far from idiomatic and pretty much require you to write imperative OOP code in SML. Meanwhile SML has existed for decades. It's one thing to say "people aren't using this great model we've developed the basics off, please help make it better", but if you wanted to write an idiomatic GUI app in SML today, your first step would be to have to write the GUI framework itself because no one else has. They don't provide any real options even if you fully buy in and want to jump in with what they're saying.

ecshafer 6y ago

But rust does have Traits which work perfectly fine for that same logic. We can just say this trait implements the Button and ToggleButton Traits.

jcelerier 6y ago
> But rust does have Traits which work perfectly fine for that same logic. We can just say this trait implements the Button and ToggleButton Traits. i've never seen that not being called oop
- ragnese 6y ago
  It pretty much is. But it's not exactly class inheritance, so most people don't consider Rust to be OOP. Structs ("classes" in Rust) can implement Traits and Traits can "inherit" each other, but structs can't inherit implementations from other structs.
  - jcelerier 6y ago
    > Structs ("classes" in Rust) can implement Traits and Traits can "inherit" each other, but structs can't inherit implementations from other structs. Right, this is textbook interfaces used for composition. Let me paste you a few paragraphs from the GoF book, released in 1994: > Inheritance versus Composition > The two most common techniques for reusing functionality in object-oriented systems are class inheritance and object composition. As we've explained, class inheritance lets you define the implementation of one class in terms of another's. Reuse by subclassing is often referred to as white-box reuse. The term "white-box" refers to visibility: With inheritance, the internals of parent classes are often visible to subclasses. > Object composition is an alternative to class inheritance. Here, new functionality is obtained by assembling or composing objects to get more complex functionality. Object composition requires that the objects being composed have well-defined interfaces. This style of reuse is called black-box reuse, because no internal details of objects are visible. Objects appear only as "black boxes." ... > Object composition has another effect on system design. Favoring object composition over class inheritance helps you keep each class encapsulated and focused on one task. Your classes and class hierarchies will remain small and will be less likely to grow into unmanageable monsters. On the other hand, a design based on object composition will have more objects (if fewer classes), and the system's behavior will depend on their interrelationships instead of being defined in one class. Like, it's the most well-known OOP design book and it states exactly that - more than a QUARTER CENTURY ago. Who in hell argues that this isn't oop ?!

anchpop 6y ago

React is a very popular GUI toolkit and it doesn't use OOP functionality at all.

andrewmcwatters 6y ago
React isn't the one doing the actual drawing.
Const-me 6y ago
https://reactjs.org/ https://reactjs.org/ says right on the front page: "Build encapsulated components that manage their own state, then compose them to make complex UIs." Components managing their own state is a textbook definition of OOP.
- wtetzner 6y ago
  Encapsulation is not equivalent to OOP. If it is, then why do we have two separate terms for the same thing?

simias 6y ago

That's one way to do it, but you could have something very similar that uses composition instead of inheritance (and a nice trait hierarchy to top it off). MyCustomToggleButton would contain an instance of ToggleButton and override some behavior while implementing ToggleButtonInterface or whatever. I don't know if that's the way to go but that'd work.

still_grokking 6y ago

As every "flat" hierarchy this is inflexible and impossible to get right (think "ComboBox" or "MenuButton" for example). A better approach are mixins. Separate ones for layout and behavior. This is much more flexible, and avoids code duplication or "crazy" inheritance hierarchies at the same time. Rust Traits are ideal for mixins. So a GUI toolkit in Rust should be just fine.

jcelerier 6y ago
> As every "flat" hierarchy this is inflexible and impossible to get right (think "ComboBox" or "MenuButton" for example). why does it work fine in Qt then ?
- rcxdude 6y ago
  It doesn't work super well. It functions, but there's all kinds of funky interface design which basically exists because of the nature of inheritance.