this post was submitted on 08 Dec 2023
26 points (90.6% liked)
Rust
6059 readers
59 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
As much as I understand why Rustaceans don't like classical inheritance, that's only a minor factor in Rust not having support for it.
Before 1.0, there was a project to solve Servo's needs for inheritance. An important point about this is how it made the question of whether inheritance is good or not moot — Servo implements the DOM, and the DOM needs inheritance, end of story.
Servo uses a bunch of procedural macros to implement OOP, and so do other projects in similar positions (GNOME, PyO3, Windows...). Anything worth adding to Rust needs to be better than that.
Solving inheritance for Servo means it needs to be as fast as C++ (the Internals thread linked above is mostly about this requirement). It's hard, because C++ doesn't prevent things like object slicing, and a safe implementation of subclassing for Rust would need to (while still providing control over an object's allocation like C++ does).
About object slicing: TFA describes inheritance as having a "hidden member variable" within a child class that's an instance of the parent class. This is mostly how it works, but it's important in trad OOP that the child class encapsulates the parent completely. For example, if you're implementing the DOM and an
HTMLTemplateElement
wants to implement its own clone and adopt steps, there should not be any way to bypass them. Also, it should not be possible to get a reference&mut Node
and usemem::replace
with a non-template, since that would still be a way to violate the invariants those methods seek to enforce.JS, Python, and WinRT are all substantially different. Covering all of them means the language features look less like a complete object system and more like a framework for building an object system.
Note: it's been a long time since I last made any meaningful contributions to Servo, and I never worked on the JS bridge code much. I'm reflecting the story as best I can. Please read the original Internals thread to get a deeper understanding of this, without creating a bad game of telephone.
Just in case anyone is interested in that the Common Lisp Object System is worth a look in this regard since it is a comparatively early attempt at making a very powerful object system that could be described in this way.