Notable for the "behaviour and state":
3. Objects have their own memory (in terms of objects).
4. Every object is an instance of a class (which must be an object).
5. The class holds the shared behavior for its instances (in the form of objects in a program list)
And more importantly, as a first sentence to explain what an object is, it's misleading and will raise a lot more questions later.
My problem is that it's not presented as a starting point or even implied that the definition might be wrong. It categorically states "The simplest notion of an object—pretty much the only thing everyone who talks about objects agrees about— is". If it had said "One notion of an object -one that many people who talk about objects agree on- is", all would be dandy. When you're stating things as fact in a document dedicated to learning, they should be solid.
My other gripe is that I've heard too many vague, biased or incomplete answers to the question "what is an object". These are structures people use every second of every day, but they've never learned a proper definition for it?
Well, "behaviour and state" is also incomplete, because it fails to mention anything about how you refer to parts of state and particular behaviours.
"a mapping of names to values and functions" on the other hand mentions both state ("values") and behaviour (functions) and also tells you that they have names.
> they've never learned a proper definition for it?
Well, there are many different valid definitions for objects, and even more for OO. There are people who don't know any of them for sure, but I strongly suspect that you've dismissed many good definitions as "vague, biased, incomplete" on the grounds of them not being your preferred one. You did it at least once just now, when you failed to realize that "a mapping of names to values and functions" is the same thing as "[named] behaviour and state".
It's possible that my dismissal of many definitions is partly because they're not my preferred one. I'm human, so it's most likely the case. I like to think my preferred one at least came about through some investigation, and it's the only one that I've seen fit a wide enough variety of cases. For me, at least part of the validation comes from the fact that I was frustrated at the definitions people gave me long before I found one I liked. Too many conversations with college teachers, mentors and colleagues that went
"So how would you define/describe an object?"
-"..."
"OK, but what about [language/edge case/model]?"
-"Oh yeah..."
Ok, after that explanation I understand what you mean. I could argue that, for example, object construction and destruction semantics are not characteristics of an object itself but rather of a particular object system or "meta-object protocol" being used; or that it's almost impossible to talk about object destruction outside of particular language context, because it relies on many different language-level features to work. But that would be too much of a hair-splitting for me :)
On the other hand I could argue that a set of functions is enough to express every possible type of behaviour and that a set of values is enough to express any possible state. But this in turn depends on the definitions of "value" and "function", which are highly language specific.
So, after thinking about it for some time, I think I can agree that "behaviour and state" is the best (possible?) definition of those which avoid diving into any implementation details and language specific features.
I'm not entirely convinced that such a definition is very practical though. You probably won't need that level of generality until you decide to implement your own object system. It won't help you (I think?) in OO design or OOP inside of some particular object system.
But anyway, you're right in that your definition is the best one in the category of "general" and "minimal" definitions of what objects are.
Sorry for ad personam in my previous comment and thanks for the discussion, it was enjoyable :)
No apologies necessary, it was absolutely fair to call me out on a bias on my end. You too thanks for the discussion :)
I don't find your definition particularly useful, either: it's too encompassing to really be of much use _to me_. By this definition just about all computation is an "object", which doesn't really tell me anything interesting.
Also, as a general pedagogic principle, I'm opposed to definitions that are too vague to say much to a middle-of-the-pack undergraduate. I'd definitely put your definition of objects in that space. It sounds like good stuff—it's certainly "quotable"—but the typical student would be hard-pressed to actually explain it or put it to use.
The usefulness is debatable. To me, it's been useful because it helped me see that, for example, a process can also be an object, and you can apply object oriented rules to interacting processes. The Actor model is an extension of that. Modelling a set of Microservices as an object model has also proven valuable.
How you communicate it to students is a not an easy matter. I'm opposed to giving definitions as an absolute truth if they aren't, even if you're doing to prove a point. If you want to teach with different definitions, that is of course perfectly fine, but at least a mention of the debate could solve some later problems. People tend to adhere to the 'laws' they learn for a long time, and if you teach them a definition that is incorrect in some cases, they'll have trouble with those cases.