On Aug 30, 2013, at 8:53 AM, Mark S. Miller wrote: > Dave Herman's "And the other consistency dimension is between array types and > struct types. Is anyone arguing that structs should also have expandos?" > surprised me, and convinced me of the opposite conclusion. Do you think > instances of struct types should be extensible?
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. 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. Allen > > > On Fri, Aug 30, 2013 at 8:48 AM, Allen Wirfs-Brock <[email protected]> > wrote: > This thread has convinced my that Typed Arrays should be born extensible. > > Actually, my subclass example in the thread started me down that path. In > many cases where you might subclass an array you will want to add per > instance state. You can expose a getter/setter on the prototype but the > state still needs to be associated with the individual instances. Expando > properties (or even better properties added in the @@create method) are the > most natural way to represent that state. > > The Firefox implementors will make this change if it represents TC39 > consensus. > > I'll put this item on the agenda for the next meeting and see if we can agree > on extensible Typed Arrays. > > Allen > > > > > On Aug 28, 2013, at 11:01 PM, Filip Pizlo wrote: > >> Here's the part that gets me, though: what is the value of disallowing named >> properties on typed arrays? Who does this help? >> >> I don't quite buy that this helps users; most of the objects in your program >> are going to allow custom properties to be added at any point. That's kind >> of the whole point of programming in a dynamic language. So having one type >> where it's disallowed doesn't help to clarify thinking. >> >> I also don't buy that it makes anything more efficient. We only incur >> overhead from named properties if you actually add named properties to a >> typed array, and in that case we incur roughly the overhead you'd expect >> (those named properties are a touch slower than named properties on normal >> objects, and you obviously need to allocate some extra space to store those >> named properties). >> >> -Filip >> >> >> >> On Aug 28, 2013, at 10:52 PM, Steve Fink <[email protected]> wrote: >> >>> On 08/27/2013 09:35 AM, Oliver Hunt wrote: >>>> My complaint is that this appears to be removing functionality that has >>>> been present in the majority of shipping TA implementations, assuming from >>>> LH's comment that Chakra supports expandos. >>> >>> Note that even in the engines that support expandos, they will probably >>> not survive a structured clone. I just tried in Chrome and they get >>> stripped off. This further limits their utility in today's Web. >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > > > > -- > Cheers, > --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
