Object-oriented Programming with ANSI-C (1993) [pdf]

There is definitely an art to it at some point, but I see a lack of tools to be a big problem.

We are in the stone-age of programming at the moment.

I think the solution is visualization.

I want to click on any variable, and see its full data-dependency graph. All the functions it flowed through and all the transformations that occurred all the way back to a single source of truth.

With this in hand, I think it would be much easier to understand how to group methods and state. We should write code such that this data-dependency graph is easily understood by humans.

I guess I mean that it's not the first thing people reach for unless they know about it. They have some data and want to write a function to do something.

But yeh its probably a too broad statement not worth debating on definitions.

The reason is implicit makes really easy to miss things and the majority of software devs have very poor understanding of coupling. Consequence is if inheritance is a thing, you'll see monsters in the code.

If inheritance is not available, the problem doesn't exist.

Same goes for immutability, in the end our tools are tuning for the lowest performers

It's just the latest hipster language trend. When OO was new, structural C was evil. When functional programming happened, everything before that was evil...

Because, yes, sharing state among classes for code reuse, is fundamentally evil... How dare you want to couple state and logic?

Almost like every single UI framework in every mainstream language has converged upon OO as the best way to model the problem at hand... GTk even invented a similar type system to what was mentioned in this PDF just to give C OOP constructs... Now witness as the Rust language has failed to produce a compelling UI/widgeting framework or paradigm, and the best ones out there are Qt-based or GTk-bindings (letting C hilariously handle the OOP for Rust).

I think inheritance is the most convenient thing which came out of OOP, but interfaces are the most valuable one.

At least for business applications, you want to keep your behaviour and state separate. And people following OOP dogmatically will (ab)use encapsulation for use-cases where your data should be transparent.

Contrast this to interfaces, which are essentially composable specifications on code-level (and I absolutely love that Java uses interfaces to describe anonymous classes due to the power it gives you for documentation and specification).

The way I'm thinking about it (just a different expression of the exact same thought) is that inheritance as a means to share code is bad, while inheritance as a means to leverage polymorphism is good. Polymorphic classes can still share code, but this should be done using composition.

Simula67, arguably the first OO language, was centered around inheritance.

The other early major OO language was obviously Smalltalk which focused on message passing.

Both C++ and Java were majorly influenced by Simula, while more dynamic languages take on aspects of Smalltalk.

State can also be shared and reused together with functions operating on it - via composition.

"Thankfully" he says.

Now witness as Rust struggles to produce a compelling widgeting environment that isn't Qt or GTk bindings to other languages which support OO constructs. Witness as apparently creating a "Rust-friendly" OO paradigm or framework is an ongoing academic endeavor, because of this...

Believe it or not, for some domains, object-orientation is the right tool for the job... as some problems are just inherently modeled better with such a paradigm, and are able to take advantage of what it has to offer (encapsulation, polymorphism, inheritance).

There's a sizable chunk of people who think that the concept of inheritance for code sharing is causing more harm than good overall. These languages make it hard to do inheritance for exactly that reason.

This is C++:

   for (auto&& x: collection)
       x.foo();

This is C:

   for (int i = 0; i < collection_size; i++)
      foo(collection[i]);

... but [1]:

  #define foo(x) x.foo(&x) 

So, no, C and C++ are more similar than you think. The biggest difference is the presence of overloading which, in the static dispatch case, makes resolving the actual function from the function name slightly harder in C++ without tool help. Overloading has little to do with OO, although it is a form of static polymorphism.

In the dynamic case they are equivalent (well except for the fact that you have to build the vtables by hand in C and the syntax is a bit awkward.

[1] yes, yes, arguments are not protected against multiple evaluation. Sue me.

[2] with emacs of course this is actually possible, just merely hard.

To be honest I don't understand your comment, I think you're talking about something else, so I'll try to rephrase.

My point is that C is not an OOPL. There's two aspects of OOP: 1) the concrete language features 2) a pseudo-philosophical wishy-washy hippie territory where nothing is clear and everything is subjective, where you view all problems as something that is to be modelled with objects, and your own mental model is firmly centred around objects.

Since C lacks concrete OOP features, I will proceed to show why the latter aspect (philosophical OOP) is problematic.

In OOP, objects are entities composed of data and functions that operate on that data. That's what C++ classes usually are: members and methods bound syntactically together. OOP doesn't allow a method to belong to two objects, by definition and by C++ syntax.

Now, let's say you have a C API that offers 2 structs, A and B, and some functions F1A(A, ...), F1B(B, ...), and so on. The people who claim C is OOP language will say "a-ha! A is an object. The data (encapsulated too!) is in type A, and the functions F1A, F2A, ... are the methods. You could write a C++ class 'class A { private: data; public: F1A(...);...};'. Same for B. See? A and B are objects!"

This is the philosophical OOP in action, where "it looks like OOP" becomes "is OOP".

So what happens if the API adds a new function, FAB(A, B, ...), that operates on the internals of A and B? If we switch back to OOP parlance, if you had two classes, A and B, and wanted to add FAB to one of them, which class would FAB belong to?

Well, it's problematic because we're dealing with imaginary objects, so the answer can be whatever you want it to be.

You can arbitrarily say "pick the first parameter type to be the object that owns FAB". Well, what if it's FAB(const char*, A, B)? And even if A is the first one, doesn't FAB changing B break the all-precious object encapsulation? Once you introduce FAB, are these objects at all?

The problem of choosing the "owner" is a common one in C++ OOP because the objects are real (there's syntax to mark something as an object), whereas in C the objects are imaginary and, therefore, a fuzzy ambiguous concept. If you take the set of all functions whose 1st parameter is an int, does that form an object? If everything is an object, is anything an object?

But, like I said, this tends to be a non-problem in C (if you're not a OOP person) because you'll recognise that FAB(A,B) does something useful, and all this conceptual objects design is just noise that does not matter and you're happy to say "my code is not OOP but it does something useful in the best possible way".

Which is why I think that philosophical OOP (object thinking) is dubious, and the only way you can call a language OOP is if it has OOP features. Otherwise, if the only thing you're doing is applying your OOP mindset, I don't think it's fair to say that the language itself is OOP.

> OOP is essentially a software architecture model.

Finally! Somebody pointed this out.

OOP is merely a different way of structuring "Procedural/Imperative" programming. In the early days of OOP hype, the greats like Edsger Dijkstra, Niklaus Wirth were rather critical of it and denied that it was something very "Original". It was correctly pointed out as merely a technique for structuring code for "programming in the large". Once you understand this you can design and use OOP (for a specific definition) in any language.

I agree that you can _imagine_ that FILE and DIR are objects, you can imagine they have behaviour, you can apply your OOP mental model to procedural code.

But it all breaks down the moment you add a function that operates on the internals of both FILE and DIR, because this function doesn't belong to any one object. And if you don't notice it, you keep thinking FILE and DIR are objects, when in fact they're not (a method can't "belong" to two objects, at least as far as objects are perceived in the software world).

In short, I can agree that it's possible to write C with a OOP mindset. But (let's call it) imaginary OOP may not be actual OOP (as when enforced by the C++ compiler).

> It isn’t a thing in a C++

But it is a thing in OOP. That's the point. C++ is multiparadigm. All the OOP gurus will tell you that objects shouldn't expose their internal data, only methods.

That's why the so-called encapsulation is constantly brought up. People telling you C is OOP will say "FILE is an object, the FILE struct + fopen/fclose/fwrite constitute an object, FILE is opaque, we can only interact with its internals through the public methods". "DIR is an object, ...". And so on.

And the problem is that when the Linux C API exposes a function that takes both a FILE and a DIR, and operates on both their internals, your whole idea of OOP-ness shatters because a method can only belong to a single object, by definition.

No seriously, the GTK C bindings are basically written in a half-formed version of the old C++ "C with preprocessor macros" syntax.

It looks like this when you program it:

    GtkWidget* grid = gtk_grid_new();
    GtkWidget* label = gtk_label_new("Hello World");
    gtk_grid_attach(GTK_GRID(grid), label, 0, 0, 1, 1);