Hacker News Reader

Rust doesn't merely have a way around the Expression Problem, the entire language & it's set of libraries is built constructively / additively bottom-up atop very dumb types, with operations added latter! Traits and impls invert the responsibility to define operations, are still static definitions & static types but late-created / created-elsewhere types, that aggregate more and more impls than the type is initially defined with. An inversion of control of typing. Dynamic but still compile-time static types.

It's refreshing to see this very clear problem statement, which feels like an ideal anti-thesis that reveals the hidden glory of Rust's traits/impls:

> It turns out that adding new operations isn't as easy as adding new types. We'd have to change the Expr interface, and consequently change every existing expression type to support the new method(s). If we don't control the original code or it's hard to change it for other reasons, we're in trouble.

> In other words, we'd have to violate the venerable open-closed principle, one of the main principles of object-oriented design, defined as:

> software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification

Apologies for the self link, but this came up very recently in a sub thread about Rust & I'm so glad to close the loop & find a name for this. I said there & I'll say again, I think this is one of Rust's Greta superpowers, that we are not trapped by the design parameters of the libraries we consume, that Rust allows us to layer in more and more to our types, as we please. An amazing superpower of Rust that imo gets way too little attention, where-as the borrow-checking tends to soak all the attention/fixation for the language. https://news.ycombinator.com/item?id=45041286#45045202

There's a whole chapter of the Rust book on Rust & OOP, btw, which provides a side-ways look at how Rust & OOP and the Expression Problem relate. https://doc.rust-lang.org/book/ch18-00-oop.html

C# and others have extension methods, where you can add operations. But most of the language & it's use is pretty conventional OOP; it's a feature not the core. Mentioned in the thread above, there's a claim that Standard ML functors have similarities to rust: I haven't investigated yet but that'a piqued my interest & I'm eager to find out at some point!

View on HN

struct A { ... } struct B { ... } trait F { ... } impl F for A { ... } impl F for B { ... } trait G { ... } impl G for A { ... } impl G for B { ... } fn some_function<T: F + G>(data: T) { ... }

use library::{A, B, F, G}; struct C { ... } impl F for C { ... } impl G for C { ... } trait H { ... } impl H for A { ... } impl H for B { ... } impl H for C { ... } fn another_function<T: F + G + H>(data: T);

struct Constant { value: i32 } struct BinaryPlus { lhs: i32, rhs: i32 } trait Evaluate { fn evaluate(&self) -> i32; } impl Evaluate for Constant { fn evaluate(&self) -> i32 { self.value } } impl Evaluate for BinaryPlus { fn evaluate(&self) -> i32 { self.lhs + self.rhs } } // Adding a new operation is easy. Let's add stringify: trait Stringify { fn stringify(&self) -> String; } impl Stringify for Constant { fn stringify(&self) -> String { format!("{}", self.value) } } impl Stringify for BinaryPlus { fn stringify(&self) -> String { format!("{} + {}", self.lhs, self.rhs) } } // How about adding new types? Suppose we want to add FunctionCall struct FunctionCall { name: String, arguments: Vec<i32> } impl Evaluate for FunctionCall { fn evaluate(&self) -> i32 { todo!() } } impl Stringify for FunctionCall { fn stringify(&self) -> String { todo!() } }