typed objects and value types

[Niko Matsakis]

> 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 <niko at alum.mit.edu> 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