On Aug 30, 2013, at 9:39 AM, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote:
> I think the right-way to think about structs is as an record structure with > no properties fixed behavior provided by a "wrapper". Very similar to the ES > primitives except that structs can be mutable. The way to associate > properties with structs is to encapsulate them in an object, preferably via a > class definition. If we go that route we can reach the point where ES classes > have fixed-shape internal state defined as-if by a struct. I might give a slightly different angle on this, and describe structs as objects with a fixed template for their own properties. They are still objects, they still inherit from prototypes. But they have a predefined set of own properties. > Typed Arrays are a different beast that already exist in the real world. I > don't see any need for consistency between Typed Arrays and struct types. > Consistency between Typed Arrays and Array is more important. Mostly agreed, except I'd just refine that to say there's no need for consistency *in this dimension*. It would be a shame if typed arrays weren't generalized by the typed objects API in general, and I worked hard to make the pieces fit together. That nuance aside, the fact that, in practice, arrays are patched with additional properties (in fact, IIRC the ES6 template strings API adds properties to arrays) suggests that non-extensibility would be a real incompatibility between arrays and typed arrays. So I'm cool with making typed arrays -- but not structs -- extensible. Dave _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
