On 4 September 2013 17:11, Filip Pizlo <[email protected]> wrote: >> On Sep 4, 2013, at 7:55 AM, Andreas Rossberg <[email protected]> wrote: >>> On 4 September 2013 16:44, Filip Pizlo <[email protected]> wrote: >>> On Sep 4, 2013, at 3:05 AM, Andreas Rossberg <[email protected]> wrote: >>>> As part of binary data, typed arrays are implicitly constructed "on >>>> the fly" as views on a backing store. Any notion of identity -- which >>>> is the prerequisite for state -- is not particularly meaningful in >>>> this setting. >>> >>> Are you proposing changing how == and === work for typed arrays? If not >>> then this whole argument is moot. >> >> No, they are just rather useless operations on data views. That >> doesn't make the argument moot. > > The point is that as soon as you're using the copy '=' on binary data > fields, you're already losing an observable notion of object identity. The > '=' here is already unlike the '=' operator for languages that have true > value types - in those languages you wouldn't be able to observe if you got > the *same* typed array or a different one but with the same underlying data. > In JS you will be able to observe this with '==' and '==='. Hence, being > able to also observe that you got a different one because you lost some > meta-data (i.e. custom named properties) doesn't change the fact that the > quirky semantics were already observable to the user.
I didn't say it's unobservable -- every twist in the gut is observable in JavaScript. I said it's rather meaningless. That is, from a practical perspective, I'd rather not recommend relying on it, unless you are up for subtle and brittle code. > As far as I can tell, this object model compresses typed arrays about as > much as they could be compressed while also allowing them to be extensible. > The downside is that you pay a small penalty for typed arrays that have an > "active" buffer, in the case that you either accessed the .buffer property > or you constructed the typed array using a constructor that takes a buffer > as an argument. I really don't feel like getting into this argument -- as I said it's a minor point. Just note that the optimisation you suggest might not be worth it in every VM (i.e., there could be a substantial impedance mismatch), and moreover, that the above case might be not-so-uncommon. /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
