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