If you are contrasting objects to pure values, that is really the main distinction: objects have names at design time, compile time, and run-time, values do not. I don't think it is unusually broad (at least it is not considered a radical position in the academic OOP community). Everything else: encapsulation, methods attached to data, subsumption, nominal subtyping, require that an object has its own identity and further support its "objectness."
Even if you didn't have these features in your language, they are fairly straightforward to construct in an ad hoc way as long as you have identity (that includes aliasing, obviously). Some kind of object system is often invented while building C programs of non-trivial size.
If the key isn't unique, then multiple objects could share the same state...they would be the same object!
I'm not sure what you mean by a "name". Do you mean the same thing as Hickey's definition of "identity", i.e. "a stable logical entity associated with a series of different values over time"?
Yes. To identify something whose fields change over time, it needs a name (even if that name is just a GUID or address). Well without fields, you don't need names, but this isn't a very interesting case (it is hard to scale up programs with just what are essentially global variables!).
Values are anonymous in contrast: you can't really tell the difference between this 42 and that 42.
> In computer science, an object is a location in memory having a value and possibly referenced by an identifier.
Not useful huh?
I would say, if the memory location is heap allocated and has mutable fields, then it is probably acting like an object (it could also be a value, it depends if its identity is important or not).
Wikipedia appears to distinguish between "object-based" languages and "object-orientated" languages. On the subject of object orientated languages, it says:
> An object has state (data) and behavior (code).
Which is the definition I'm most familiar with. I wouldn't class a Clojure reference as an "object", as it has state but no inherent behavior.
> I would say, if the memory location is heap allocated and has mutable fields, then it is probably acting like an object
So a reference to an immutable map wouldn't count as an object for you, because there are no mutable fields?
The reference to the immutable map doesn't count (a immutable map is just a value), but keys into the map can form objects (in that they represent "object" properties). Actually, that is how you get objects without first class mutability (identities must still be generated, of course, which is the same thing).
Ya, the wiki article makes a distinction between programming and designing with objects, and object-oriented programming. It really. All my arguments are about designing and programming with objects vs. designing and programming with values, call it "programming with objects" if you must.
Even if you didn't have these features in your language, they are fairly straightforward to construct in an ad hoc way as long as you have identity (that includes aliasing, obviously). Some kind of object system is often invented while building C programs of non-trivial size.
If the key isn't unique, then multiple objects could share the same state...they would be the same object!