[asgeir]

I would still classify that as object oriented behavior.

You have a class/type of objects, and you have a set of functions or operations which are associated with (loosely or tightly) and operate on that type of object.

For example, I would say that file descriptors are a handle to a type of object. They encapsulate the thing that they represent (file, DRM buffer, eventfd, whatever), and some of the functions that operate on them are polymorphic. For example, read, close, ioctl, etc., don't care if the file descriptor is a file, a queue, or whatever.

You use syscalls to interact with file descriptors, but they are just as much object handles.

[ChrisMarshallNY]

It definitely is. I was just talking about the definition of "an object."

It separates the functionality from the object. Turns it into an external stimulus to change the state of an object.

I used this pattern, back in the 1990s, to make a C API behave like a C++ API. This was back when every compiler had a different stack convention, and the only one we could rely on, was C.

To be fair, I did have function pointers, in some of the objects, that acted as "poor man's vtables."

I know that the API was still in use, 25 years later.

[asgeir]

It's possible that we are talking at cross purposes.

I think you might be arguing that the object itself does not include the set of functions/methods/operations that act on it, whereas I see them as another attribute of the class/type which is an attribute of the object.