Hmmm. I already don't like it when we're collecting together "procedures and state".<p>One of the most poisonous things about the "class" whether that's in Java or C++ is that it <i>looks</i> 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!<p>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.<p>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.<p>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 <i>tonne</i> of procedures for Thingys.<p>This also makes sense when I don't have total information. If you give me a Thingy, <i>I</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 <i>unless</i> you provide procedures. Maybe <i>you</i> have procedures, but I can't necessarily use them.