I have no idea how defining the type of a function's domain is supposed to be indicative to dynamic dispatch or associated methods with classes. I think I don't understand your example :-( Perhaps you can elaborate, since I don't know much about either of these languages.

Regarding existential types: yes, there's an intimate relationship between existential quantification and OOP. But you can distinguish the difference between OO languages and (non-OO languages with existential types) in the type theory. That's what's important. I think the raw empirical nature of my academic community consensus test is far preferable to the author's epistemological argument.

The question is whether OOP has meaning. I think if the PL community can be empirically demonstrated to have enough consensus that languages are reliably categorized as OO or non-OO, then we can safely say the term has meaning regardless of any armchair philosophy to the contrary.

Edit: And I think (hope) the author of the article would agree my test is sufficient. He states: When I say that there’s no such thing as OO, I mean, more precisely, that there exists some abstraction (or several) that is referred to as “object-oriented”, but that this abstraction has no actual referent in reality. It is an abstraction that is made in error. It is not necessary, and serves no cognitive purpose. It is “not even false”..

If OO has enough meaning to an important subgroup of people that they can use it with more-or-less consensus, then the claim that it has no referent in reality is clearly empirically denied, at least for that subgroup. And if that subgroup happens to be a large chunk of the PL community, then I think that's an important enough subgroup to settle the larger question.

CLOS is completely, thoroughly, dyed-in-the-wool object oriented. It gives you generic functions which dispatch methods, by considering the class type of every (specializable) parameter. CLOS also avoids the silly problems by not putting methods into a class scope and dealing with symbol-table conflicts upon inheritance: like when inheriting from "graphical" and "lottery", working out whether the "draw" method renders pixels, or performs a lottery pick.

The CLOS design absolutely nails OO, and that's even before we look at the meta-object protocol.

Great, thanks! Your example makes a lot more sense now.

The easy way out is to say that these languages are OO in the same sense that Java is functional. Easy but maybe not unfair, particularly since all are dynamically typed.

The clojure examples make this look like OO. I would have to find a formal definition of the semantics to figure out if there's a more nuanced explanation than the easy one above.

And yes, I think I agree with the last bit. The author's observation that lines can become blurred is certainly valuable and true. It's the author's conclusion that the term OOP is therefore meaningless which is, imo, empirically false.

edit: stray punctuation

Those are function overloads? Does it pick the overload based on the runtime type of a variable that can hold multiple types? Can you create arbitrary multi-member types to apply this logic to?

Then code using that dispatching to implement behavior would be object-oriented, I think.

If not then no.

Also it's code that's object oriented or not, a language 'being' object oriented is a discussion of how well it supports such a thing. But they're all turing compatible; with enough abstraction you can write any type of code on top of any language.