i suggest to extend Rust with classes like in c plus plus but instead to think a class, and multi hierarchy like in c++ , to think a class like a macro structure of code, so the code continue to be super fast but it is possible to create a big project organizing code in a hard logic and reusable structure
Rust doesn't need classes, you can use structs and traits to organize your code just as effectively (if not more effectively).
What do you think is lacking in Rust that classes can improve?
3 Likes
I read but they dont answer my proposal. I specified do not reimplement class as designed in c++. Yes ,Apparetly is similar but in the language compiler is very different using macro power. The idea do not overload the heap is right , but is not sufficient. It is necessary goes foward. It is necessary imagine new solutions.
I think you need further explain what you are looking for, then.
1 Like
See also this article:
For decades, since the introduction of C++ and Java I have wondered about OOP. Initially I did not see the urgent need for it. Latterly I thought I was just too stupid to get the idea. Something was wrong with OOP and I could never put my finger on it or express what I meant well. If I ever tried to talk about it fellow team members would start to look at me sideways.
In recent years I noticed that slowly that people were speaking up and expressing their issues with OOP. Talking of what an unmaintainable, unmodifiable, unreliable mess OOP could make of a project.
I don't recall who it was but someone discussing design patterns a few years ago concluded that every design pattern was an indication of something broken or missing in your programming language. Notice how the C++/Java world talks of design patterns all the time.
Today, the OOP problem is a common topic of conversation, the article linked above being a fine example.
Then came Rust. Finally a language that offers actually new and useful features, especially of course it's concepts of data types, mutability, aliasing, thread safety, and so on.
Perhaps I'm wrong but I get the idea that trying to add OOP as in C++ classes, inheritance, etc is would be hard to impossible whilst keeping the those Rust features.
I would not like to see Rust get run over by Java refugees and adopting a "class" keyword. As happened to Javascript.
6 Likes
Multihierarchy is very importart in complex project. The architecture of the code is the most important thing for creating a solution working with many components, working seeing the future and not only the present, for the best fitting the problem , for reasoning for the best algorithmic model . Performance is very important and i love rust. It introduced many smart concepts (sincerelly i thought similar many years ago) but it is necessary be smarter and smarter. We are not sufficient smart 
Without a hard logic schema the algorithms are confused and the open source development is collapsing. There is a reason if java is used in the most prototypes and research software. Pay attention to the fine differences because in a macro system a butterfly can change completely the solution and the model.
I have worked on two rather large commercial Rust codebases, and we had no trouble with the tools available to us. You have to explain in much much more detail what you are proposing, because if it's different from what I know as classes, then I don't know what it is.
And repeating the word smart does not really help me understand.
3 Likes
Good code organization and good API design can be done even in C, OOP and classes will not help with that. The original SmallTalk ideas of what OOP is were
- message passing
- isolation of objects
- polymorphism
There's nothing that mentions inheritance, it's just one way to achieve polymorphism, just like how traits can do the same. Hierarchical organization and isolation of what each object/type can see is done by organizing the code in modules, using the pub and pub(crate) modifiers. Then message passing is implemented in channels. Rust is just as "true OOP" as Erlang, imo...
2 Likes
Just to add to the previous:
Alan Kay himself wrote this famous thing and said "The notion of object oriented programming is completely misunderstood. It's not about objects and classes, it's all about messages".
2 Likes
it is sufficient for example a superstruct as already now a sypertrait exists.
because when you face a complex software you have to decompose the logic structure (also the data driven part) in parts and subparts. In addition you have necessity to decompose the logic structure in sub crates for resusability for parts usable also in other contexts. So for my opinion it would be better to add a superstruct concept similar to supertraits. Composition and decomposition is the most powerfull rule for giving to the developers community the possibilty to design. The composition and decomposition must be expressible in any aspect of a programming language. If you cut a aspect , you cut a branch of expressivity and so on of ideas , projects,....
Adding inheritance to structs is not that simple. Now if I have a variable of type MyStruct, the compiler can no longer know how large that type is, because it might be some subtype with more fields. Similarly currently if you call a method, the compiler knows exactly which function you are calling, and can hardcode the location in the binary of that function, but if a subtype overloaded it, you need to go look up where the actual function is every time you want to call it.
This will essentially mean that you have to allocate every single value of every type on the heap, and every single function call must use dynamic dispatch. A significant performance impact.
Traits are already very powerful. There are other ways of doing things than using object oriented principles, and when you truly need dynamic dispatch, trait objects are still there to help you.
2 Likes
you continue to think a superstruct as superclass.... a superstruct is including simply the data contained in parent struct. Compiler can make simply a sum. You have to imagine just if you copy directly some field in the extended struct. Nothing else. You can do it directly with a preprocessor.
struct A{ int a;} struct B : A {int b} is equivalent to { int a; int b; }
So you want something that can copy the fields over? You can just include A as a field in B and call it a day. This has been suggested many times, I suggest you try out the search box, and find one of the many threads on this subject.
yes but it is not the same in the organization of code. It works in the same way but le logic structuration/organization if different
What makes you think that structs wrapped in other structs are larger in memory? And I don't think animal should be a struct — that doesn't make much sense.
Look, Rust is not an object oriented language, and the way you are used to structure programs is not the only one. If you want to use an object oriented language, go use one instead of trying to change Rust into one. Rust simply has a different goal than Java.
struct A{ int a;} struct B : A {int b} is equivalent to { int a; int b; } = 4+4 = 8bytes
struct A{ int a;} struct B {A a, int b} is equivalent to { int a; int b; } = 4+4+4(or 8) = 12 or 16 bytes redepnding how much is reference address. For navigating the structure cpu makes also a additional hop.
Rust doesn't use pointers when you put one struct inside another. See this playground. Their fields are simply next to each other.
This is one of the reasons you can't easily add inheritance to e.g. A. Suddenly the B struct would no longer know how large the first field is, so it doesn't know where field2 should be.