In traditional object-oriented languages (e.g. Java), it is possible to "extend" the functionality of a method in an inherited class by calling the original method from the super class in the overridden version, for example:
class A {
public void method() {
System.out.println("I am doing some serious stuff!");
}
}
class B extends A {
@Override
public void method() {
super.method(); // here we call the original version
System.out.println("And I'm doing something more!");
}
}
As you can see, in Java, I am able to call the original version from the super class using the super
keyword. I was able to get the equivalent behavior for inherited traits, but not when implementing traits for structs.
trait Foo {
fn method(&self) {
println!("default implementation");
}
}
trait Boo: Foo {
fn method(&self) {
// this is overriding the default implementation
Foo::method(self); // here, we successfully call the original
// this is tested to work properly
println!("I am doing something more.");
}
}
struct Bar;
impl Foo for Bar {
fn method(&self) {
// this is overriding the default implementation as well
Foo::method(self); // this apparently calls this overridden
// version, because it overflows the stack
println!("Hey, I'm doing something entirely different!");
println!("Actually, I never get to this point, 'cause I crash.");
}
}
fn main() {
let b = Bar;
b.method(); // results in "thread '<main>' has overflowed its stack"
}
So, in case of inherited traits, calling the original default implementation is no problem, however, using the same syntax when implementing structs exhibits different behavior. Is this a problem within Rust? Is there a way around it? Or am I just missing something?
This isn't possible directly now.
However, RFC 1210: impl
specialization contains various aspects that will make this sort of behaviour work, for example, something like this should work:
trait Foo {
fn method(&self) { println!("default implementation"); }
}
trait Bar: Foo { ... }
partial impl<T: Bar> Foo for T {
default fn method(&self) { println!("Bar default"); }
}
Doing a super
call is explicitly mentioned as an extension to it and so won't necessarily appear immediately, but may appear in future.
In the mean time, the approach generally used is to define a separate function for the default behaviour and call that in the default method, and then users can emulate the super::...
call by just calling that function directly:
trait Foo {
fn method(&self) { do_method(self) }
}
fn do_method<T: Foo>(_x: &T) {
println!("default implementation");
}
impl Foo for Bar {
fn method(&self) {
do_method(self);
println!("more");
}
}
That said, Rust favours composition over inheritance: designs that work well in Java can't and shouldn't be forced 1-to-1 into Rust.
Foo::method(self); // this apparently calls this overridden
// version, because it overflows the stack
The qualified path syntax, Trait::method(value)
is sugar for <Type as Trait>::method(value)
where Type
is the type of value
(or, possibly, the type after dereferencing some number of times). That is, it's calling the method on the specific type as you found out.
Is this a problem within Rust?
No, this is working as intended
Is there a way around it?
You can move the method to a free function and then call it directly, once from the default method and once from the "overridden" method.
fn the_default() {
println!("default implementation");
}
trait Foo {
fn method(&self) {
the_default()
}
}
struct Bar;
impl Foo for Bar {
fn method(&self) {
the_default();
println!("Hey, I'm doing something entirely different!");
}
}
fn main() {
let b = Bar;
b.method();
}
Or am I just missing something?
Rust is not an object-oriented language, Rust may be an object-oriented language, but not all OO languages are created the same. Rust may not quite fit into the traditional paradigms that you expect.
Namely, traits don't exist at run time. Only when they are applied to and used with a struct is code generated that is callable. When you create your own implementation of a method, that supersedes the default implementation; there's nowhere for the default method implementation to exist.
Often times, your code can be written in a different way. Perhaps the truly shared code should be extracted as a method on a new struct, or maybe you provide a closure to a method to customize the behavior.