It doesn't seem uncommon for someone to generally like Rust but still want to use something OO for UI. I'm in that boat. Never liked OOP much, but it makes sense sometimes.
Implementation inheritance can be achieved with good old shared functions that take trait arguments, like this:
fn paint_if_visible<W>(widget: &W, ctx: &mut PaintCtx)
where
W: HasBounds + HasVisibility,
{
if widget.is_visible() {
ctx.paint_rect(widget.bounds());
}
}
You can also define default methods at the trait level.
This all ends up being much more precise, clear, and strongly typed than the typical OO inheritance model, while still following a similar overall structure.
You can see real world examples of this kind of thing in the various GUI toolkits for Rust, like Iced, gpui, egui, Dioxus, etc.
But it's not "kinda how you can do it in C". Traits are a core feature of Rust, any non-trivial Rust program uses them. Traits alone give you polymorphism across disparate types, exactly as in OO - actually better than standard OO (without interfaces), because trait polymorphism works without requiring inheritance from a common ancestor.
> Especially because there's no GC.
This is the only real issue I can think of. However, for implementing something like a UI, automatic GC isn't really necessary because the lifetime of widgets etc. maps very well to the lexical/RAII model. Windows own widgets, etc. Again, see all the UI toolkits implemented in Rust.
I know the Rust trait system has an answer to every OO concept. Another is that data field inheritance is replaced by composition. But these are more workarounds for the rarer cases you want to do OO in Rust, not the intended usual path, and doing OOP this way will get tedious. Otherwise, there'd be no difference and everyone would call Rust an OO language.
Not so sure about not needing GC. Many times a problem seems easy without GC until you get into the weeds. Like why did ObjC feel the need to add ARC (not GC but similar goal)?
> But these are more workarounds for the rarer cases you want to do OO in Rust, not the intended usual path, and doing OOP this way will get tedious.
It sounds like you're speculating. But this doesn't match the reality of actual Rust code. For example, here's the complete, actual code for the `Widget` trait implementation for the `Button` struct in the egui framework:
This is OO code. It's just that it's trait-oriented, not class-oriented. But that's a good thing, not a drawback. Traits are more precise, more flexible, more type-safe, and don't conflate multiple unrelated concerns in a single feature the way class inheritance does. OO languages like Java support a very similar approach, via interfaces.
You can find similar code in any Rust GUI library, and indeed in almost any non-trivial Rust program.
> Otherwise, there'd be no difference and everyone would call Rust an OO language.
Rust is not a class-based OO language. But the fact that one of its core features, traits, have "methods", and those methods have a first argument traditionally named `self` should be a clue. Trait-based OO is very much OO. Whether "Rust is an OO language" depends on how strictly you want to define "OO" to match the rather obsolete 1970s conception of it.
This is why the first question I asked you was "What OO features are you thinking of that Rust doesn't have?" Because "OO" is a broad label that covers a wide range of different features.
Rust doesn't have "classes", but classes are a 1970s-era mish-mash of a whole bunch of different concerns munged together into a single poorly-factored construct. Now, half a century later, that's well understood, and better solutions exist in the form of traits and interfaces, and related capabilities.
> Like why did ObjC feel the need to add ARC (not GC but similar goal)?
Same reason Rust includes `Rc` and `Arc`. A general-purpose language has to provide some solution to memory management based on reachability. Reference counting and tracing GC are common solutions to that. Rust's static memory management plus RC is plenty good enough for GUI applications.
Indeed, chapter 18 in The Book stops short of claiming that Rust is object oriented. But it's clearly written to highlight the good parts of object-oriented design that Rust has adopted.
Every "OO for UI" approach I've seen breaks most of the rules of object-oriented design.
GTK, Qt, DOM, WinUI 3, Swing, Jetpack Compose, and GWT (to name a few) all provide getters and setters or public properties for GUI state, violating the encapsulation principle [1]. The TextBox/EditBox/Entry control is the perfect example.
The impedance mismatch is that a GUI control is not an object [2]. And yet, all of the object-orient GUI examples listed implement their controls as objects. The objects are not being used for the strengths of OO, it's just an implementation detail for a procedural API. The reason these GUIs don't provide an API like shown in [1] is because it's an impractical design.
"How are you supposed to design an OO TextEdit GUI control if it can't provide a getter/setter for the text that it owns?" Exactly. You're not supposed to. OOP is not the right model for GUIs.
Ironically, SwiftUI doesn't have this problem because it uses the Elm Architecture [3] like React and iced.
[2]: From [1], "All the rules in the rule-of-thumb list above essentially say the same thing — that the inner state of an object must be hidden. In fact, the last rule in the list (“All objects must provide their own UI”) really just follows from the others. If access to the inner state of an object is impossible, then the UI, which by necessity must access the state information, must be created by the object whose state is being displayed."
