Skip to content

@mitchmindtree /traitmethodoverriding.rs
Last active

Embed URL

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
The ability for derived traits to override their parent trait methods.
// Firstly - I LOVE Rust! This is just something that has
// been cropping up more and more in my Rust coding experience
// recently, so I though it could be good to discuss it with
// fellow Rustaceans!
//
// TOPIC:
// I'd love the ability to be able to override parent trait
// methods with default methods in the child trait.
//
// The following is a pattern that I come across very often:
trait Foo {
fn create_a_thing(&self) -> Thing { ... }
fn another_really_handy_method(&self);
}
trait Bar: Foo {
fn create_a_thing(&self) -> Thing { ... but uniquely } // this is what I'd love to be able to do! (See below for a better syntax suggestion)
}
struct A {..}; impl Foo for A {}
struct B {..}; impl Foo for B {}
struct C {..}; impl Foo for C {}
struct D {..}; impl Bar for D {}
struct E {..}; impl Bar for E {}
struct F {..}; impl Bar for F {}
fn create_all_the_things<T: Foo>(creators: &Vec<Box<T>>) {
for creator in creators.iter() {
println!("{}", creator.create_a_thing()); // Here, `create_a_thing` would get called uniquely for those that implement Bar if overriding were possible.
}
}
fn main() {
let a = box A{..};
let b = box B{..};
let c = box C{..};
let d = box D{..};
let e = box E{..};
let f = box F{..};
let creators = vec!(a, b, c, d, e, f);
create_all_the_things(&creators);
}
// My real case scenarios have many, many more than just 6 types,
// but hopefully you can see what I mean (and how this might be
// useful) with this small example.
// SYNTAX:
// Perhaps an explicit syntax could be used to make overriding
// parent trait methods both possible, and easy to keep track of:
trait Foo {
fn create_a_thing(&self) -> Thing { ... }
}
trait Bar: Foo {
over<Foo> fn create_a_thing(&self) -> Thing { ... but uniquely } // `over<Trait>` tells us exactly what trait owns the method that we're overriding.
}
// Maybe we could be even MORE specific (and help the
// compiler out) by requiring explicit syntax upon Foo's
// version of the method as well?:
trait Foo {
virtual fn create_a_thing(&self) -> Thing { ... } // `virtual` indicates the ability for the method to be overridden.
}
trait Bar: Foo {
over<Foo> fn create_a_thing(&self) -> Thing { ... but uniquely } // The overridden version
}
// MODULE PROBLEM:
// "But what if you're using a `MyType` that has implmented
// `Bar`, but only `Foo` is imported into the module?"
//
// POSSIBLE SOLUTION:
// Then the compiler should produce an error stating
// that "MyType's implementation of Foo's "create_a_thing"
// method has been overridden - import the overriding trait
// to fix this."
// These are my humble thoughts. What are your thoughts?
// I realise that Rust draws quite a lot more inspiration
// from the FP paradigm, but I feel this could help a lot for
// those who are coming from slightly more of an OOP background.
// It's a pattern that crops up quite often in OOP, but with the
// right explicitness, I feel that Rust could do it better than
// it has ever been done before!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.