typed objects and value types

[Andreas Rossberg]

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