Claude Pache wrote:
Le 4 août 2013 à 18:23, Brendan Eich<[email protected]> a écrit :
You must mean by 'objectness' reference-not-value semantics -- typeof returning "object" or
"function" and the user ruling out null value (or opting into "null" result) doesn't do a
thing to reject non-extensible, no-own-property objects of course.
/be
There is a problem of terminology about what is called "object", and it will
lead to confusions if not amended:
* For some technically reasonable definition of "object", Value Objects are
objects.
* But for most programmers grown in a world where there is only Primitives and non-Value
Objects (let's call them "Reference Objects"), Value Objects are better
classified in the group of Primitives than in the group of Objects.
Yet without wrappers being typically observable or ever wanted. Just
confirming here ;-).
I tend to take the "dessert topping and floor wax" approach. And indeed
Object.isObject(0L) === Object.isValue(0L). Both!
The reason is that Value Objects share the following features with Primitives,
which constitute the practical important differences between them and Reference
Objects:
* intrinsically immutable, with no own property;
* comparing by value.
The fact that Value Objects does not need wrapper in order to act like an
object is an implementation detail that has almost no practical significance in
the day-to-day life of the programmer (well, true, it will not break
`instanceof`...).
No more than instanceof is already broken, or cross-realm promiscuity is
already broken (see "Realm, Schmealm!").
Incidentally, the fact that `typeof` evaluates to "object" for most Reference Objects but
for almost no Primitives, reinforces the association of the word "object" to Reference
Objects.
Here there's a bigger difference users must attend do: not only null,
but "function". The "function" result is not a matter of indifference or
unwanted complexity as wrappers are -- it's JS's equivalent of Python's
callable, we hope (it has not been, due to "host objects", but we're
working to fix this).
In this very thread, there have been at least three people in three days who have
spontaneously called "object" things that are exclusively Reference Objects,
although the very subject of this thread tells loudly that there is another kind of
objects:
* myself: https://mail.mozilla.org/pipermail/es-discuss/2013-August/032545.html
(where `Object.isObject()` ruled out Value Objects in my meaning);
* Brandon Benvie: https://mail.mozilla.org/pipermail/es-discuss/2013-August/032553.html
(where "objectness" rules out Value Objects);
* Bruno Jouhier: https://mail.mozilla.org/pipermail/es-discuss/2013-August/032561.html (where
"objects (mutable)" is in contrast to "values (immutable)")
Granted, but people are good at implicit learning and language
adaptation. I'm not blowing it off, trying to put it in its proper
place. But I'm game to explore alternatives too:
One radical solution is to revise the definition of "object", so that Value Objects are not objects. For
example, what is currently called "object" would be named "thingummy", while the label
"object" would roughly apply to intrinsically mutable, compare-by-reference thingummies.
Indeed in SpiderMonkey ages ago, I had an object < thing < value
ontology reflected in naming conventions (object is-a gc-thing, string
is-a gc-thing, both are values, boolean is-a value but not-a gc-thing,
etc.).
Another less radical thing to do, is to de-emphasise the notion of "object"
from the API, by excluding things like `Object.isObject` (programmers need rather
`!Object.isValue`, anyway).
I'm about ready to drop Object.isObject per your last message. But again
it discloses something harder to discern otherwise.
How about Object.isReference?
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
