> 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 u

> 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.