I have an application in Python that has two editions, pro and standard. The entire application is structured in this way, where there is a pro class and a standard class for various aspects of the system. Depending on whether user is pro or standard, a different class is used. This design leans h…

I would make the Pro struct simply encapsulate a Standard struct and have them both implement a common trait. ▶ Sample Implementation: click to exapnd Edit: Another approach would be to create an enum with Standard & Pro as variants instead of using Box/dyn in the sample provided.

[image] naim: Edit: Another approach would be to create an enum with Standard & Pro as variants instead of using Box / dyn in the sample provided. I like that idea. Something like struct Standard { ... } enum Either { S(Standard), Pro { s: Standard, fancy: String, }, } Th…

Your example code is a blessing thanks. Regarding your edit/second approach ... would you mind showing where in your example this would be implemented? thanks!

No prob. :slight_smile: Well, I think it would be convenient to have the enum implement the common trait so something like this could be done: enum Editions { Pro(Pro), Standard(Standard), } impl Edition for Editions { fn do_something(&self) { /* saves the previous Box<> alloc…

Is there really a hierarchical relationship between Pro and Standard? Even your own example casts doubt on this assumption: calling Pro::do_something prints did it in a standard way followed by did it professionally, which seems like a contradiction. If you wanted to only print did it professionally,…

Is there really a hierarchical relationship between Pro and Standard ? Even your own example casts doubt on this assumption: calling Pro::do_something prints did it in a standard way followed by did it professionally , which seems like a contradiction. True my example probably isn't good from t…

So in that case I might write something like this : impl<E: Edition> Application<E> { fn do_something(&self, arg: String) { let arg = self.edition.encrypt(arg); println!("I'm doing {}!", arg); } } trait Edition { fn encrypt(&self, arg: String) -> String { arg // …

Taking a similar approach to what @trentj proposed, you can go a long way in doing pseudo-OO in Rust: Please appreciate how neat the field accesses are working out... use std::ops::{Deref, DerefMut}; use derive_more::{Deref, DerefMut}; use enum_dispatch::enum_dispatch; #[derive(Clone, Debug)] str…

I just thought to mention that if you don't need different data for the two versions, you could avoid using methods at all for the Standard/Pro distinction. e.g. something like enum Edition { Standard, Pro } fn do_something(data: ..., more_data: ..., edition: Edition) { Do stuff... if let Edi…

@droundy I need to separate the Pro and Standard code entirely - into different files - because the Standard is a different license to the Pro. The standard version needs to work with 0% knowledge of anything about the pro version.

Newbie question: what's the idiomatic way to do Python-style inheritance in Rust?

TomP October 17, 2020, 5:41pm 13

The second Rust koan provides insight into the limitations of inheritance vs. Rust's traits and methods approach.

Topic		Replies	Views
How to implement inheritance-like feature for Rust? community	21	72517	August 11, 2019
With composition over inheritance in Rust, how does one implement shared state to go with shared behaviour? help	22	18143	September 14, 2020
What is the right way of achieving Inheritance in rust	11	11306	February 22, 2022
Suggestion for making Rust's trait system more usable for generics community	74	5590	January 14, 2020
Python-like inheritance help	5	1019	November 10, 2022

Newbie question: what's the idiomatic way to do Python-style inheritance in Rust?

Related topics