101–110 of 149 posts
A whole book on this topic was already written in 1993 by Axel-Tobias Schreiner. It seems to be freely available nowadays: https://www.cs.rit.edu/~ats/books/ooc.pdf (edit: link updated to point to author's website)
I wasn't too keen on this book. I read it hoping it would be more like the article in this post. But I felt it was more a case of someone re-inventing c++ with macros.
Earlier quoted context omitted.
Rust has a flavor of inheritance through Traits and #derive.
No, traits are not inheritance, nor is derive that is default implementation of some traits. Traits are like interfaces in OOP languages (simplified), the equivalent of a class would be a struct + all the impls of that struct. And that thing cannot be extends, a struct is fixed when defined and nobody can extend it, you can use composition that is the correct to me way to go.
Traits describe the methods implemented, and you can override with specific implementations or inherit the default, from a level up.
Earlier quoted context omitted.
Rust has a flavor of inheritance through Traits and #derive.
Traits implement interface inheritance, yes. #derive has nothing to do with derived classes in OOP, it's an annotation-like facility that adds auto-generated code to any object.
TLDR: Put data members in a struct. Write a function per "method" and pass in the `this` pointer. Simple and effective. BUT: inheritance. C++ has subclasses (`class Manager : Employee`) and virtuals / vtable lookup on pointer access (`employee->name()` which calls `Manager::name` or `Employee::name` based on type). What is the typical equivalent in C? Hand-rolled vtables? Or is there a general paradigm that helps to…
Earlier quoted context omitted.
Eh, this is a very separate debate. You don’t need OO for modularity. This should be obvious. You need an API/Contract and for re-use you need a “module” (such as a dll or a web interface). For example something like: int CreateTheStatefulThing(blah* thing); DoStuffWithThing(blah* thing); void CleanUpThing(blah* thing); To suggest OOP is the foundation of reusable code is simply wrong.
You are reading in to what I wrote something I did not say. I said that "OOP has become the foundation," not "OOP is the foundation." There is a very big, historical, fact-based distinction between those two statements. Modularity and reuse are completely different things. A highly modular codebase is more amenable to write reusable code, but many modular systems have been written with very little concept and code re…
You cannot separate theory and practice in the way you are attempting to. It’s not just “bad books” that lead to the abuse of inheritance that is so familiar, there were (and are) broken concepts that only became visible with time.
I highlighted “module” for a reason, because one of the key mistakes of practitioners was to view the element of re-use as the “class”. In reality if we want to create a reusable component the boundary is much higher. We create an api and a library or some other component that can be distributed.
Building a reusable component is much more work, and recognising when that is necessary and designing accordingly is an important engineering discipline.
To finish with a snipe of my own; I think people who take an OOP is primary view of the world need to do a little more programming in lisp to properly understand the fundamentals.
Earlier quoted context omitted.
https://news.ycombinator.com/item?id=34220101
This isn’t a religion. I really don’t see what is so controversial about suggesting OOP has clearly failed on the majority of its original stated goals. That’s not to say that nothing has been salvaged from the wreckage; languages like Rust are a great example of retaining what actually was useful.
A whole book on this topic was already written in 1993 by Axel-Tobias Schreiner. It seems to be freely available nowadays: https://www.cs.rit.edu/~ats/books/ooc.pdf (edit: link updated to point to author's website)
The webpage in the title is pretty good. It explains most things you need to achieve OOP in C. This PDF however pushes C for what it is not intended for, which leads to inefficient and obscure code. For example, the first example in the PDF implements a Set. Everything is "void". This loses typing and will make code hard to read and maintain. The way inheritance is mimicked is hideous and inefficient. The PDF also he…
> However, C is not C++ and is not intended for providing all OOP features like inheritance.
There are parts of the ISO C standard specifically included to allow for inheritance. Consider:
typedef struct{ int x; }struct_a;
typedef struct{ struct_a inherited; int y; }struct_b;
void function(struct_a *s) { s->x = 0; }
Here struct_b inharates struct_a. You can call the function with either a pointer to struct_a or struct_b (either by casing or void pointer), because the standard specifically states that there can be no padding before the first member of a structure, so that the first member of a structure should have the same pointer as the structure itself. This part of the spec was written with the use case of inheritance in mind. (there is some people who don't read the spec that way, but this is the intention)
Sorry for being nitpicky... but that's pretty much what we do in the wg14....
Earlier quoted context omitted.
You are reading in to what I wrote something I did not say. I said that "OOP has become the foundation," not "OOP is the foundation." There is a very big, historical, fact-based distinction between those two statements. Modularity and reuse are completely different things. A highly modular codebase is more amenable to write reusable code, but many modular systems have been written with very little concept and code re…
Anyone who disagrees with you is simply poorly read and uninformed? You cannot separate theory and practice in the way you are attempting to. It’s not just “bad books” that lead to the abuse of inheritance that is so familiar, there were (and are) broken concepts that only became visible with time. I highlighted “module” for a reason, because one of the key mistakes of practitioners was to view the element of re-use…
Look, you don't like OOP, who cares? I certainly don't. But that's different than trying to explain that you have a fundamental misunderstanding.
Whether you accept it or not, it's in your head now ;)