typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting
claude.pache at gmail.com
Mon Aug 5 15:04:22 PDT 2013
Le 5 août 2013 à 19:14, Brendan Eich <brendan at mozilla.com> a écrit :
> Claude Pache wrote:
>> Le 4 août 2013 à 18:23, Brendan Eich<brendan at mozilla.com> 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.
>> 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.
I'm confident that anyone sufficiently nerd to want to take advantage of the difference between primitives and value objects, will know how to do it without our aid. :-)
You're right that people are good at language adaptation, thus it is not necessary to go as far as to change the nomenclature. The main concern remains, that they use today `Object.isObject` by meaning probably `isReferenceObject`, so it is prudent not to standardise something else under this very name.
> How about Object.isReference?
Instead of `!Object.isValue`? Indeed, for me I test more naturally for a Reference Object ("is it an Object-like or not?") than for a Value. Plus, `s/ \b Object.isObject \b / Object.isReference /xg` would refactor some expected legacy code in an twinkling of an eye.
More information about the es-discuss