# Typed objects
Ron Buckton (TypeScript), Yulia Startsev (SpiderMonkey), Shu-yu Guo (V8) and Dan (Igalia) met to discuss typed objects.

## Agreed-on MVP goals

- **Reliable shape**: A typed object should have just one "hidden class", and not change hidden classes during execution (unless we come up with a very good reason to do so). This is half of what it means to be "typed"; the other half is that the values of the fields have reliable "types".
- **Reliable access performance**: If a particular code path has just one kind of typed object flowing through it, then reads or writes to fields should be highly optimizable (both with ICs and the JIT). So typed objects make it more likely that you'll be on the engine's "happy path". (Note that access performance may vary due to factors outside of the JIT, e.g., memory system performance for shared objects.)
- **Compact in-memory layout**: Typed objects should be efficiently representable in memory. For example, engines should be able to pack together small integer fields, and avoid the need for "tagging" any kind of value in memory, as the GC should be able to trace the type declaration to see whether something is a pointer or not.

## Relationship to other kinds of classes/objects

- **Normal JS classes**: It would be nice if it were not too taxing to refactor normal JS classes and objects to typed objects. This could boost adoption. For example, it would improve usability if typed objects could have methods somehow or other. It's to be expected if this transition requires some changes, but they should be easy to understand for developers.
- **Wasm GC proposal**: This proposal should facilitate incremental adoption of WebAssembly, in conjunction with the Wasm GC proposal, by letting developers write classes *either* in JavaScript with typed objects *or* in WebAssembly with the GC proposal and produce a roughly similar interface to be used from both JS and Wasm -- it should be possible to use them so that the class implementation language to be a mostly-unimportant detail. It is fine if there are some differences (especially in the form of capabilities that exist on one side but not the other), but it should be possible to explain the big picture to JS/Wasm developers.
- **TypeScript**: It's important that typed objects and their classes can have their types checked by TypeScript. It's not expected that existing TS types can magically serve as types for fields of typed objects, but it should be possible to explain to TS developers how to upgrade a class to typed objects. It should also be possible syntactically to give TS more detailed type information than is communicated to JS at runtime.
- **The JavaScript object model**: Typed objects may be "exotic objects" (like TypedArrays), but must fit within the current JavaScript Meta-Object Protocol (i.e. be expressible as a Proxy). For example, there won't be a new property attribute for the type of a property.

## Agreed-on non-goals (at least for the MVP)

- **Subclassing**: Adds a lot of complexity (e.g., for instantiation), and not needed for as many use cases.
- **Guards** (a full type system for JavaScript): This is just overshooting, for now, as the topic is complex and it's easy to get wrong. Better to make incremental progress on the most useful part first.
- **Backing ArrayBuffers** (as in the original typed objects proposal): This wouldn't work for all typed objects, since some of them will contain pointers. Instead, the core model is that each typed object is an individual allocation.

## Interest in prototyping
- Ron has a prototype of a **polyfill** which he could extend to whatever semantics we develop.
- **V8** will be looking into prototyping some kind of concurrent, racy objects
- **SpiderMonkey** has been transforming their typed objects implementation to match experimental Wasm GC work and would like to align that with this proposal
- **Igalia** (in partnership with Bloomberg) is interested in prototyping typed objects in **JSC** later in 2021

## Other goals
Individuals in the meeting had additional goals, which may not be shared by the whole group:
- Dan and Ron wanted typed objects to have a class-based definition syntax for better ergonomics and more reliable static analyzability. This is a desired property of the MVP for them, whereas others may be OK with this as post-MVP.
- Shu wanted to permit some typed objects to be used in a concurrent, racy way, in read-copy-update (RCU) patterns. https://docs.google.com/document/d/1OXEhv5Jr48pt2wJOwzwAScuuu_Y0YS2gmIFikRd4gVc/edit#
- Dan wanted to think about bitfield support (fine as post-MVP, as Yulia and Shu indicated).
- Ron wanted typed object support for cases like FFI and interactions with linear memory (unclear how/whether this could have a unified representation to other cases, to others). In this case, it would be important to be able to represent things like packing or endianness.
- Ron noted that we may want operator overloading to be limited to typed objects (while Shu saw operator overloading as highly unlikely). Operator overloading would certainly add complexity.
- Shu and Ron expressed interest in various kinds of homogeneous arrays of tyepd objects; this might be an MVP goal.