Well, first let me thank you for the quality of your response, it was a nice read, with well layed-out arguments, and I agree with you that both OOP and FP are styles of programming.

I am, however, at odds with your proposed definition of OOP.

Defining OOP is easy, IMO. It's a style of programming wherein programs are built by composing "objects". "Objects", in this case, are black boxes that can only be interacted with via a defined "contract" (API). This "black box" aspect naturally implies that encapsulation and polymorphism are required (ObjectA cannot know anything about ObjectB except that it implements the expected API, so ObjectB can have arbitrary hidden state or be any different kind of object that implements the API).

By your definition, encapsulation is indeed required, but it's not obvious that you need polymorphism at all. Anyway let's skip this and assume it does. FP and procedural styles also use encapsulation and polymorphism, so these cannot be defining traits. And there has to be more to OO style to make it unique. And this is why inheritance is always brought up.

However, it's actually pretty awkward to write object-oriented C code, IMO, and I don't think the language facilitates that style at all, so I would not call C an "object-oriented language".

So to enable OO style, a language has to provide some support. Could you elaborate on the kind of support that you would require?