> What makes OOP wrong is not tying methods to data, but tying data to ontologies. Limiting a function to operating on what something "is" is an artificial limitation. Limiting a function to operating on what something "has" or "can do" is a logical consequence.
But the “is”es in proper OOA&D, and hence OOP (at least the ones you should be coding to), are of the form “is a thing that can do”.
If you mean: never declare a function as taking a particular class instance ("is"), only interfaces/traits/mixins/whatever ("has" / "can do").
Then yes, we agree.
As soon as you declare a function as taking a class instance, you're limiting to what something "is". I don't think ontologies are particularly useful as a means of abstraction.
Yes, you can do better with careful architecture, but the footgun is still there and I'm just saying we should probably get rid of it instead of working around it.
But the “is”es in proper OOA&D, and hence OOP (at least the ones you should be coding to), are of the form “is a thing that can do”.