Extend a type from 3rd party

But I need to extend type by state.

These conversations always remind me of the blub paradox:

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

Different languages are designed around different paradigms and like to solve problems in different ways. When you first start learning a new language you see all these weird things and when the language doesn't allow the approach you would normally use, you label it as inferior.

You wouldn't try to shoehorn mutations into Haskell or functional programming into C, so why are you fixated on using inheritance to solve your problem when Rust made the conscious decision to disallow inheritance?

1 Like

But the thing is that rust simply doesn't have yet solution to that problem and all there is are messy workarounds.
Until they get their act on and provide proper ways to do things:

"We do intend to add a mechanism for inheritance similar to this to Rust, but it is likely to be some time before it reaches stable Rust"

I'm not gonna write tons of boilerplate just because language doesn't provide proper and supportive to developer way to reuse code.

Why not clone the repo, do what you want and use that repo in your project? Also, one of the maintainers of that repo is very open to PR's so take a shot and make life easier for everyone.

Can you explain the end results you are trying to achieve without making assumptions on how it will be implemented?

The way you've worded things so far ("I want to extend that type, so that I have all the functionality the type provides plus my members and fns", "I need to extend that type so I can have all the functionality of that type + fiels string containing the name of that table", etc.) are phrased assuming an inheritance-based solution. Then you are getting frustrated when people say "that's not idiomatic, maybe you should try a different approach?"

There is probably a much easier way of implementing things but we can't see it at the moment because the discussion has gotten bogged down on inheritance.


This assumes that I have the time to work on somebody's code as well as time to work on mine. And I just don't have that luxury.
Plus, what in C++ is a matter of creating another type that inherits from other, here in rust, we are getting into cloning repo and actually working on 3rd party code to use it... And that's one type only. What if I need to have functionality of other type and that other type is in another library? Do I have to clone another repo again? Do you see how unworkable and unscalable that solution becomes?

Like I've said in my OP.
There is a type in 3rd party lib. I need all of the functionality of that type in my type + some new members.
Tbh, I would love if there was much easier way to achieve that in rust.
I just want to make clear - I learn rust because I like it and I see lots of good things about it. But the lack of inheritance is simply a weak point.

Coincidentally, I've been using that repo for the last couple of days and stumbled on what I think is the same problem that you have: not being able to find out information of a specific table. (like this issue) Would you mind being more specific on what it is you want, specific to cursive, that is?

I need to extend TableView from cursive_table_view crate.
But also, learn a technique how to reuse 3rd party code, that is extend its functionality without actually touching 3rd party source code.

I know that. My question is why you need to do that. You mentioned something along the lines of getting the name of the table, but it's still unclear what you want, specifically.

Like I've said, I want to extend the functionality of that type by adding some members, name is just one of them.

You keep mentioning extending the type, but that is making an assumption about the implementation. What are you trying to do with the extended type. What problem are you trying to solve?

1 Like

I'm trying to use 3rd party type - as my own with extra information/state.

The 3rd party type I'm trying to extend doesn't have all the information that is required for my specific application. Just to give you an example.
3rd party type: TableView - has all the basic functionality I need. You can populate it and you can scroll through the items.
But it doesn't have information about, which rows are of what colour, just to name one functionality is missing and that I require.
Doesn't have the timestamp it was last updated/modified - I need that.
And others...

This is the kind of information people are asking for. Can you flesh this out more, perhaps with actual code? If you can give a concrete example of a single problem you want to solve, I bet someone can give you a solution that would work well.

pub struct MTableView {
    table_view: TableView<A, B>,//this is 3rd party

I need amongst others:

  1. store colour each row of that table has
  2. Timestamp that table was updated

Well, this still isn't much information. In general, the more specific and detailed your question, the easier it is for people to understand and help. For example, I doubt many people in this thread have actually used TableView, so it would help to provide a description of what it is and what you need to do with it. Otherwise, you put the burden on others to figure out the context by themselves.

That being said, from a brief look at the TableView library, the suggestion by @Cerber-Ursi seems reasonable to me in this situation. @rikyborg warned that

I would agree with that generally. But in this specific case, I think there might be good justification. Specifically, you want to create your own struct that is is a TableView. It has all the same responsibilities of TableView, with a few added features. I think the same argument applies to String; it essentially is a str, so it implements Deref<Target = str>.

I think @rikyborg's advice still applies though. I wouldn't think of this as inheritance, at least not in the traditional OOP way. And I would be careful with the features you add to MTableView. Make sure that it always represents a TableView and nothing more.

If you end up wanting a type that does more, you could also consider implementing AsRef<TableView> for MTableView. With that approach, you take a slight hit to ergonomics, because you need to call .as_ref() before each TableView method. But it also makes "composition over inheritance" explicit, which I find vastly preferable.

I gave you all the information and the purpose I need that information for. I really have nothing else to add.
Basically I want to have TableView with extended capabilities.
For the moment it seems to me that the only sensible approach to it is to implement Deref.
Great pity rust doesn't (yet) provide mechanisms for inheritance.
Thanks for all the help.

My thinking exactly.

The question being asked is why do you want this?
If you don't want to/can't say why, please say so.