On Thu, Sep 5, 2013 at 4:29 AM, Filip Pizlo <[email protected]> wrote:
> > > This is where I return to the objectyness point: typed arrays are already > spec'd to have a bunch of heavy reference-to-object behavior. So making > then expandable is no big deal. And making then non-expandable means that > we'll now live in a weirdo world where we have four different concepts of > what it means to be a value: > > A) Full blown reference objects that you can do weird things to, like add > properties and change __proto__, etc. You can also make one non-extensible > at your discretion, which fits into the bat-poop crazy "you can do > anything" philosophy of full blown objects. And that's great - that's the > heart of the language, and I happen to enjoy it. > > B) Object types that are always non-extensible but otherwise still objecty > - they have a prototype that is observable, they reveal their identity via > ==, and you can actually inject stuff into them by modifying the > appropriate Object.prototype. > > C) Values with whatever value type semantics we come up with in the future. > > D) Primitives. > > Now, I hope that we could get C and D to be as close as possible to each > other. But that still leaves three different behaviors. This introduces a > learning curve. That's why (B) offends me. It's subtly different from (A) > and clearly different from either (C) or (D). > > Now, we actually also have a totally alternate behavior, used by binary > data. And my argument there is that I wouldn't get too offended by binary > data acting weird, because the very notion of exposing binary data is weird > to begin with. I expect it to be used only for special graphicsy stuff and > not for general-purpose "value types" for normal JS programs. So it's OK > to me if binary data is both weird and inconsistent with everything else. > And no, I still don't view "typed arrays" as being part of binary data - > it already appears to be the case that typed arrays have different buffer > behavior to the struct types. So they're just different. And that's fine. > > You are underestimating the diversity of species in (A). You *can* create "full blown reference objects" that are non-extensible in plain JavaScript today: just call Object.preventExtensions(this) in constructor! So (B) *as you define it* is a subset of (A). Note however that typed arrays as implemented by many vendors today are neither in (A) nor in (B) - you can extend typed array with _named_ properties, but you cannot extend typed array with _indexed_ properties. There is no "Object.preventIndexedExtensions", so this sort of (non-)extensibility is indeed a weird case. If the goal is to reduce the zoo of object kinds, making typed arrays completely non-extensibie puts them firmly in (A): they are just full-blown objects that happen to be born non-extensible - something that is already totally possible in the language today. As to binary data acting "weird": it might appear weird, but this is again the kind of "weirdness" that is possible in JavaScript *today*, as evidenced by Dave Herman's and mine polyfill: https://github.com/dherman/structs.js. (almost; there are subtle differences re whether struct fields are data properties or getters/setters, but the key behaviors of assignments and equality are modelled accurately). Dmitry
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
