> I think the idea that value types should be objects would > require stretching the notion of object too far, and violate one of > the fundamental properties that objects currently have.
Certainly this was the idea, though I didn't think of it is as violating, but rather... stretching. :) > Other properties, like the ability to use an object as keys in weak > collections, follow from that. If we suddenly allowed objects that do > not have identity, but a structural notion of equality, then we could > not allow these objects into weak collections. Interesting point. I hadn't thought about weakmaps (though it seems like an obvious next step from thinking about *maps* in general). > Either way, I think we should refrain from introducing a completely > new, hybrid form of value that behaves neither like a primitive nor > like a proper object. I will ponder this for a bit and write another e-mail shortly. :) I want to try and draw up what I see as the family of alternatives. I feel like to some extent the question of "primitive or object?" is perhaps a distraction, though I made it sort of central to the blog post for some reason. The real question is to derive the properties that user-defined values must have, and then we can see whether it seems to fit better into the system as a whole to stretch primitives or to stretch values. Along those lines, user-defined values (uvalues) probably ought to have the following characteristics: - uvalues are (shallowly) immutable - uvalues have no "generative identity", and are compared using "by-value" === - uvalues have a prototype linked to their def'n - the syntax 'uvalue.foo' can be used to access members of this prototype - when transmitted between realms, uvalues retain this link - uvalues cannot go into weak maps, but can go into other maps/sets Does this sound about right? Clearly I left open the question of what typeof yields (which I don't feel *especially* strongly about, actually, I don't have much intution for what `typeof` *means* to people) and whether `uvalue.foo` works via a wrapper or some other mechanism. Niko On Wed, Apr 02, 2014 at 05:01:10PM +0200, Andreas Rossberg wrote: > On 2 April 2014 16:32, Niko Matsakis <[email protected]> wrote: > > I just wanted to let people on es-discuss know about two of my recent > > blog posts concerning typed objects. The first is a kind of status > > report: > > > > http://smallcultfollowing.com/babysteps/blog/2014/04/01/typed-objects-status-report/ > > > > and the second details some (preliminary) thoughts on how one could > > build on typed objects to support user-defined value types: > > > > http://smallcultfollowing.com/babysteps/blog/2014/04/01/value-types-in-javascript/ > > That is very helpful, thanks! I agree with a lot with what you say. > But to expand on my reply to your blog post, I have one fundamental > concern: I think the idea that value types should be objects would > require stretching the notion of object too far, and violate one of > the fundamental properties that objects currently have. Namely, > objects have generative identity. > > Other properties, like the ability to use an object as keys in weak > collections, follow from that. If we suddenly allowed objects that do > not have identity, but a structural notion of equality, then we could > not allow these objects into weak collections. That would break a > rather fundamental assumption, and make a distinction between > different sorts of objects that does not exist before. > > It would also have other unpleasant consequences. For example, if > value types yield objects, then these objects could be proxied. But a > proxy could not simulate their structural notion of equality, at least > not right now. So we'd need to extend the proxy API. Being objects, > you could also use value type instances as prototypes, which seems a > rather useless feature as well, but would potentially cause a lot of > pain for VMs. > > (For what's it worth, all these arguments also apply to typed objects > and their interpretation as fat pointers, which are essentially a > special case of value type.) > > Either way, I think we should refrain from introducing a completely > new, hybrid form of value that behaves neither like a primitive nor > like a proper object. To me, it seems a much more elegant and economic > model to extend the notion of primitive type. That is, make value > types primitive-like, use the existing wrapping semantics, let them > have an implicit prototype link, and typeof different from "object" > (whether something fixed or actually user-defined is debatable). > > /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
