3 ms·

I'm not sure I really understand the point of this exercise but I'll play along. I'm not going to write in that EDN + CoffeeScript pseudocode. I don't really l

I'm not sure I really understand the point of this exercise but I'll play along. I'm not going to write in that EDN + CoffeeScript pseudocode. I don't really like those kind of types without pattern matching. I do wish JS had keywords though. Lets use modern JS and pretend that JS objects are simply heterogenous maps of String -> any... let cat = { talk: () => "Meow" }; let person = { thinkingAbout: "Politics", talk: (self) => `Have you heard about ${self.thinkingAbout}?`, thinkAbout: (self, topic) => self.thinkingAbout = topic }; function invoke(object, method, ...args) { return object[method](object, ...args); }; invoke(cat, 'talk'); invoke(person, 'talk'); invoke(person, 'thinkAbout', 'TV'); invoke(person, 'talk'); That'd be one example of a very bootleg object system. If you want examples on how to build an object system so you can do OOP in a language that doesn't intentionally support OO... look into the Common Lisp Object System, or for some object-oriented C code (there's a lot of it out there), or see Chapter 3 of SICP: https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book-Z-H-20.html#%_sec_3.1.1 https://mitpress.mit.edu/sites/default/files/sicp/full-text/... Both of your new examples are more OO than your last one. CLOS is basically something like what we've been doing + way more effort than either of us is going to put into this. Your switch statement example was such a straw man it's hard to even say what was wrong with it. Polymorphism in OOP replaces switching on type every time you define a method. This isn't a rule, but I think OOP should be on the opposite side of solutions to the expression problem from switch statements and pattern matching. Again: In the mind of the average dev any construct that doesn't exactly mirror the semantics of classes isn't OOP. There are people who didn't consider JS to be OO because it didn't have classes. (It still doesn't, but it pretends to so they say "now its OO".) I really can't stress this enough. The languages we were talking about before aren't extreme straw man examples of OOP, like these snippets are. EDIT: I should add with regard to these examples that I don't think it's necessary that data and behavior be grouped in definition as long as they can be treated so at the site of invocation even if the methods are invoked in the same manner as free functions.

didibus 8y ago
Before I go any further. Just want to thank you for the thorough exchange we had. And maybe we'll have to agree to disagree on this one. Which is to be expected in a discussion about the name of things. That said. I did learn about some particularities of deftype in the process, so it was a win for me. Okay, now I continue. > I'm not sure I really understand the point of this exercise but I'll play along I'm just trying to see what are the concrete characteristics that are relevant to you to classify something as OO. Would be great if you could list them out. But I'm trying to reverse engineer them right now. With my prior examples, I was demonstrating the difference I see between OO and a functional approach to type polymorphism. In #1, data and behavior is grouped together inside the object. Thus you access the object to look up methods to call. The object is thus front and center. In #2, data and behavior are not grouped. The function is front and center. You first call the function, and it looks up an implementation for the type of its argument(s). To me, this ordering matters. It's the difference between FP and OO in my eyes. Similarly, I don't consider #2 to have objects. There's just tagged records and functions. While #1 has what I consider objects, a structure capable of grouping data and behavior. This order is even reflected in the syntax differences between OOP and FP. Where in OOP you use "noun.verb", because the method is on the object, and you go through the object to get to it. While in FP you use "verb nouns", because the function is first class, and it's the one doing the dispatch, the nouns are just dumb data. If you look at this, it's also obvious why FP languages are more likely to support multiple dispatch. The function can easily choose an implementation based on all its arguments. > Both of your new examples are more OO than your last one. What makes it so? It's especially confusing to me because you also said: > I should add with regard to these examples that I don't think it's necessary that data and behavior be grouped in definition as long as they can be treated so at the site of invocation even if the methods are invoked in the same manner as free functions. And this is true of my function that has a switch/case in it. Is OO the act of looking up functions to call in a datastructure based on type? This is the only definition that seems to not contradict with what I feel you're saying.

didibus 8y ago

Before I go any further. Just want to thank you for the thorough exchange we had. And maybe we'll have to agree to disagree on this one. Which is to be expected in a discussion about the name of things. That said. I did learn about some particularities of deftype in the process, so it was a win for me. Okay, now I continue. > I'm not sure I really understand the point of this exercise but I'll play along I'm just trying to see what are the concrete characteristics that are relevant to you to classify something as OO. Would be great if you could list them out. But I'm trying to reverse engineer them right now. With my prior examples, I was demonstrating the difference I see between OO and a functional approach to type polymorphism. In #1, data and behavior is grouped together inside the object. Thus you access the object to look up methods to call. The object is thus front and center. In #2, data and behavior are not grouped. The function is front and center. You first call the function, and it looks up an implementation for the type of its argument(s). To me, this ordering matters. It's the difference between FP and OO in my eyes. Similarly, I don't consider #2 to have objects. There's just tagged records and functions. While #1 has what I consider objects, a structure capable of grouping data and behavior. This order is even reflected in the syntax differences between OOP and FP. Where in OOP you use "noun.verb", because the method is on the object, and you go through the object to get to it. While in FP you use "verb nouns", because the function is first class, and it's the one doing the dispatch, the nouns are just dumb data. If you look at this, it's also obvious why FP languages are more likely to support multiple dispatch. The function can easily choose an implementation based on all its arguments. > Both of your new examples are more OO than your last one. What makes it so? It's especially confusing to me because you also said: > I should add with regard to these examples that I don't think it's necessary that data and behavior be grouped in definition as long as they can be treated so at the site of invocation even if the methods are invoked in the same manner as free functions. And this is true of my function that has a switch/case in it. Is OO the act of looking up functions to call in a datastructure based on type? This is the only definition that seems to not contradict with what I feel you're saying.