Has this been discussed here before? Thoughts? https://twitter.com/jjcarett2/status/1399473063515889672

I don't think so. Let me guess before looking: object capabilities. And nope. It's about "service abstractions" sounds like encapsulation. What did you find compelling?

(I find the whole topic this way)

"different object-oriented implementations of a type can interoperate" as the big idea presented here – interesting

I mean, this old essay of mine uses the same kernel VFS example to make the point. It's all well-trodden ground for old timers, which might be why I'm so bored with these arguments by this stage. 😜 https://jackrusher.com/journal/on-object-orientation.html

I have so many thoughts, I should probably not take the time to write them all here. Let me just say a few things. First I love Cooks definition of object oriented programming. Making a version of OO that does not use mutable state at all is really interesting. After reading his paper I went and played with my own little Cookesque OO language written as a dsl in clojure https://github.com/jimmyhmiller/PlayGround/blob/master/oop.clj But even though I really like what Cook has to say, I really don’t like this paper. First I think that these sorts of “service abstractions” are bad. They in my view almost always lead to unreadable messes of programs where understanding the behavior requires following several layers of indirection just to get at something that could have been stated very directly. But further, I don’t think the extensibility they want can only be achieved through these sorts of abstractions. I think react and its move away from classes is a great example of this. React is exactly the sort of framework they are talking about and yet, you can do full extensibility without needing these sorts of abstractions (functional react + hooks to be clear). Now just to give the caveats, I’m not saying there is never a use case for service abstraction. But what I am saying is if I could get rid of one technique that I see used over and over again in application code bases, that would be it. Yes, objects can do the things the author described, but should we really do those things? Most of the time no.