> I would argue that objects are nothing more than a uniquely identified run-time entity. With that identity, they can easily have their own encapsulated state (since their identity can be used as an address or key into a global map), and can be associated with behavior that is selected dynamically.

I largely agree and believe this is pretty consistent with the commonly accepted definition of an object in the Comp Sci sense. There are a couple examples which immediately come to mind (Smalltalk, Objective-C) along with other languages (Ruby, Perl, Python) having the ability to selectively provide equivalent behaviour.

Where I previously said "largely agree", the point where I disagree is when you state "objects are nothing more than a uniquely identified run-time entity." Objects also have associated with them a set of messages which are either intrinsic to the environment's definition of what minimally constitutes any object's behavioural contract, identified by the definition of the object's type, or some mixture of the previous two along with a mechanism to resolve message dispatching.

> Compare this with the dual of an object, the value, whose identity is determined by its structure alone (e.g. 1 and 1 are the same values), and so does not allow for state, nor does it allow for dynamic behavior selection without first turning them into objects (aka boxing).

Here, I think we disagree as not all languages treat values as being disjoint from objects. I realize you mention boxing, which languages such as C# and Java perform for _their_ definition of "plain old data" types, but this is not the same as languages such as Ruby, which represents all values as objects intrinsically.

> The only fallacy, I think, is ascribing a notion of objects based on a couple of mainstream data points.

The fallacy which I mentioned is in thinking that a person has the same checks in JavaScript applied to collaborations as is expected in other OO languages/environments. I view this as a direct consequence of JavaScript objects being hash maps. Supporting this view is:

> A JavaScript object is an unordered collection of variables called named values. (source: http://www.w3schools.com/js/js_object_definition.asp)

Good well-developed object abstractions have that feature, but that the intrinsic "objectness" that leads to such a feature being desirable does not. Plenty of us remember working with proto-objects that did not have these features, but the nature of our objects drove us to re-discover this feature on our own (e.g. by rolling your own v-tables for a pointer to a struct in C!).

> Here, I think we disagree as not all languages treat values as being disjoint from objects. I realize you mention boxing, which languages such as C# and Java perform for _their_ definition of "plain old data" types, but this is not the same as languages such as Ruby, which represents all values as objects intrinsically.

Again, I'm going for a definition of objectness. That Ruby treats values as objects isn't necessarily a good thing, and programmers will definitely want to often treat these as values anyways even if the language is resistant to that; e.g. somehow getting 1 == 1 to evaluate as true rather than false! Valueness is just as important as objectness, and in most programs we use both to certain degrees (even if our languages support one over the other).

> JavaScript applied to collaborations as is expected in other OO languages/environments.

We can argue whether it is a good design choice compared to other OO languages/environments, but it definitely makes them "objects."

>implications of object-ness lead to certain styles of computation (noun-based)

i understood that

>just as they do for values (expression oriented and functional).

but wasn't sure what you meant there. could you elaborate?

thanks.