There seem to be several definitions of "object-oriented" being thrown around here.
In general, I only consider something "object-oriented" with relation to user-controlled runtime polymorphism. Virtual functions, base and derived classes, etc. Just having an "object" with "member functions" alone is not object-oriented to me.
For example, Cario is an object-based C library. It has clearly defined constructors and destructors. It has "member function", which take an "this" object as well as other parameters. There are a lot of C libraries that are object-based in this way.
DSA brings an object-based system to OpenGL. But it is not object-oriented, per my definition. Object orientation, actual user-defined derived classes with polymorphism, would be utterly useless for a low-level graphics API. What, are you going to derive from a "program object"? What methods would you override? And why would you want to?
If you just want to affect how the GPU compiles the shader, wouldn't that be something you do as part of the creation of a program object? No need for actual inheritance; just write a simple factory function.
What does it mean to derive from a buffer object? What would you be able to affect by deriving from one? Or from a texture object? What are the user hooks for such objects?
There aren't any. Information in OpenGL only needs to flow in one direction: from the user to the object. So while making the API object-based would be good, allowing OpenGL code to call user code (which is ultimately what polymorphism is) is not. There simply are no places in the API where this is worthwhile.
What about, "it looks nonsensical and arbitrary, and is hard to explain to someone learning it?" Does that count? Oh right, you said earlier, "i am very much against api designs that try to prevent the programmer from making mistakes". So obviously, an API shouldn't be graded on whether it is simple and clean; an ugly API is just as good as a clean one.If your reason is that "it looks ancient", don't expect anyone to get you seriously.
Spoken like a true C programmer.I don't know of a single benefit for any API to be object-oriented.
"any API", not just a low-level graphics API. So, I guess just about every GUI system ever made is wrong, even though the inheritance model works quite well for a GUI (though WPF has its own take on this model).
I certainly understand wanting to pushback against over-reliance on OOP. But that doesn't mean that it shouldn't be used where it is warranted. It's no more of a religious argument to say you should never use something than to say that you should always use something.
At all times, you should strive for the appropriate use of something. You should know where it is a good idea and why it is a good idea there, and where it is a bad idea and why it is a bad idea there. Few are the programming techniques that are wholly without merit.
... what? D3D doesn't have any parent-child relationships among its objects. It has owner-creator relationships. But there is no actual object hierarchy in D3D.all the oo is about is what is parent of what. Take the microsoft's d3d apis for example. With every next version they keep changing that. They themselves can't decide which is "more right".
Um, yes actually. That's where deferred contexts come from. Microsoft didn't add those just for their health, you know.d3d10 lacks the "DeviceContext" interface present in d3d11, instead everything there is just in the "device" interface. But does this lead to any performance or other problem? No.
