4 ms·

Hmmm. I already don't like it when we're collecting together "procedures and state". One of the most poisonous things about the "class" whether that's in Java

Hmmm. I already don't like it when we're collecting together "procedures and state". One of the most poisonous things about the "class" whether that's in Java or C++ is that it looks as though this procedure called "chirp" and this state called "loudness" are snuggled up together in my Bird class, after all in my source code they are literally on adjacent lines! Of course they're not, the actual mechanics are the same as in say Rust, where "chirp" lives in an impl block, while "loudness" is part of the actual data structure, or a language with full blown Uniform Method Call Syntax where the relevance of Bird to a "chirp" procedure is just spelled out wherever "chirp" is defined, not in the data structure of Bird itself. I think the heart of OOP is the opacity, the fact that we (for some definition of we) aren't allowed to poke around in the state directly, and this article talks about that idea at length, critiquing people who build a whole bunch of getter and setter mechanics for what is, in practice, just Plain Old Data and not really an object at all. So I think I'd start there, not by adding procedures. So, I think a Doodad which may have internal state but we can't touch it, is an Object, even if there seemingly aren't any procedures for Doodads at all. But a Thingy, which has six named integers and a string inside it, that's not an object in the OOP sense, that's just some data, even if I have a whole tonne of procedures for Thingys. This also makes sense when I don't have total information. If you give me a Thingy, I can do things with that, regardless of whether you provide procedures, but if you give me a Doodad, I can't do anything with that unless you provide procedures. Maybe you have procedures, but I can't necessarily use them.

randomdata 3y ago
> I think the heart of OOP is the opacity, the fact that we (for some definition of we) aren't allowed to poke around in the state directly At the heart of OOP is being able to throw a message out into the world and maybe find another actor willing to respond to it. It is not so much that you are not allowed to poke around in the state of other actors, but that you fundamentally cannot know what other state exists without breaking the paradigm. > So I think I'd start there, not by adding procedures. Agreed. A thin veneer over internal state does not fix a break in the paradigm. > if you give me a Doodad, I can't do anything with that unless you provide procedures. You aren't even given Doodad, per se. Under OOP, you just send the message out there. If Doodad chooses to respond, then so be it. If Doohickey responds instead, such is life. Who responds is not your concern.
lioeters 3y ago
> If you give me a Thingy, I can do things with that, regardless of whether you provide procedures, but if you give me a Doodad, I can't do anything with that unless you provide procedures. This is one of the issues I've experienced with overly eager "everything is a class" style of programming. The plain old data gets wrapped up and partially hidden, complected together with procedures. The other aspect is that plain old functions get wrapped up too, and can only be accessed by instantiating the class, and complected together with state. This style of code can make the underlying data and algorithms harder to work with, less flexible, too specific to the exact architecture designed by the author - especially as hierarchy of classes, which extend the "complectedness" in more dimensions where they're tied up with each other. I just want typed and structured "thingies" as plain old data, that lets me reach in, access and modify everything as my own. Then separately, I want stateless plain old functions that accept those and other thingies of the same shape, wherever they come from, however they're created. That way I can use them by themselves, without being tied to any associated state, for my own purposes. Sometimes I think the problem is too much "architecture", where all the parts are fused and can only be used together; whereas I prefer a "toolset" or "workshop", a coherent collection of parts that are independently useful and usable.

randomdata 3y ago

> I think the heart of OOP is the opacity, the fact that we (for some definition of we) aren't allowed to poke around in the state directly At the heart of OOP is being able to throw a message out into the world and maybe find another actor willing to respond to it. It is not so much that you are not allowed to poke around in the state of other actors, but that you fundamentally cannot know what other state exists without breaking the paradigm. > So I think I'd start there, not by adding procedures. Agreed. A thin veneer over internal state does not fix a break in the paradigm. > if you give me a Doodad, I can't do anything with that unless you provide procedures. You aren't even given Doodad, per se. Under OOP, you just send the message out there. If Doodad chooses to respond, then so be it. If Doohickey responds instead, such is life. Who responds is not your concern.

lioeters 3y ago

> If you give me a Thingy, I can do things with that, regardless of whether you provide procedures, but if you give me a Doodad, I can't do anything with that unless you provide procedures. This is one of the issues I've experienced with overly eager "everything is a class" style of programming. The plain old data gets wrapped up and partially hidden, complected together with procedures. The other aspect is that plain old functions get wrapped up too, and can only be accessed by instantiating the class, and complected together with state. This style of code can make the underlying data and algorithms harder to work with, less flexible, too specific to the exact architecture designed by the author - especially as hierarchy of classes, which extend the "complectedness" in more dimensions where they're tied up with each other. I just want typed and structured "thingies" as plain old data, that lets me reach in, access and modify everything as my own. Then separately, I want stateless plain old functions that accept those and other thingies of the same shape, wherever they come from, however they're created. That way I can use them by themselves, without being tied to any associated state, for my own purposes. Sometimes I think the problem is too much "architecture", where all the parts are fused and can only be used together; whereas I prefer a "toolset" or "workshop", a coherent collection of parts that are independently useful and usable.