You should read the chapter. Apparently even Alan Kay doesn't quite agree with your view. Also please note that I did not offer this as a _definition_. What I wrote, quite carefully, was: “pretty much the only thing everyone who talks about objects agrees about”. I stand by that, because there are people who don't agree with what you say.

Alan Kay disagrees that objects exist to 'encapsulate state'. I agree with him. They also encapulsate behaviour. While it's difficult to get a precise overview of Kay's definition (he never gave them explicitly), this page does a good job of collecting the various bits: http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented

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)

But my point is that I don't agree that an object is "a value that maps names to stuff". I bet even Alan Kay would disagree, seeing as he was a proponent of the Actor model style of working, where objects exchange messages instead of method calls or values. In that case, there are no names to map, there is incoming data that matches a protocol. The object itself determines what behaviour to enact on its own state. Seeing an object as just values and methods is too simplistic, and at the same time too vague to mean anything.

And more importantly, as a first sentence to explain what an object is, it's misleading and will raise a lot more questions later.

Diving into the middle of a large and complex document and extrapolating from that is always a dangerous venture. The style of the book is to gradually reveal things as it goes along, often even starting with incorrect statements, because we learn best when we see missteps, not only from perfect solutions. Therefore, there's nothing wrong with "starting from" a statement that may not be where we end up. It's meant to be a pedagogic instrument, not a dictionary or other book of definitions. Every chapter is written in this style.

I agree, my gripes are not with the entire document, or even with the chapter in question. I also don't have a problem with starting from a statement that may be wrong in an informative way, it's a valid approach to learn a subject.

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?

> My other gripe is that I've heard too many vague, biased or incomplete answers to the question

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

How you refer to state or behaviour is not strictly relevant to the definition of an object, because it depends on how you implement it. It might fit in the language it was used in, but it doesn't in others. Behaviour might be reactive on state changes, it might be perpetual in a nameless loop, it doesn't matter. In the same vein, referring to state as values and behaviour as functions is too narrow. The lifecycle of the object is part of its state too, an object's construction and destruction is part of its behaviour. That may sound like hair-splitting, but it can seriously trip you up and give you a wrong idea of what an object is in non-conventional settings. An object is more than a map of 'name' to 'value or function'.

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

I'll gladly have this conversation again, and again, and again, and I hope somebody can poke holes in the definition I prefer, and put me on the other side of it.

The difference between you and me is that I've seen enough different notions of object (and defined some of my own) that I don't believe there is any such definition. In class I discuss why, but it's difficult to transcribe such an interactive discussion; but it is essentially the other side of "this conversation again, and again, and again".

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.

It's definitely possible that there is no one good definition, but it's a good discussion to have. I applaud that you treat this with your class.

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.

> [...] An object is more than a map of 'name' to 'value or function'.

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 :)

The practicality is a very personal thing. For me, it's helped me see that a wider variety of things match the definition. Realizing an Actor model, communicating processes, microservices or nodes in a storage model can all be seen as objects, and applying some object oriented modelling techniques to them, has been a very powerful tool for understanding them and building them. This value is entirely personal to me, though.

No apologies necessary, it was absolutely fair to call me out on a bias on my end. You too thanks for the discussion :)