On Sep 4, 2013, at 2:41 PM, Brendan Eich <[email protected]> wrote:
> Filip Pizlo wrote:
>> I agree that both of these aspects of binary data are quirky. My
>> observation is that prohibiting custom properties doesn't fix the underlying
>> issue.
>>
>> [snip]
>>> var MyArray = new ArrayType(...);
>>> var MyStruct = new ArrayType({f: MyArray});
>>> var struct = new MyStruct(...);
>>> var array1 = struct.f;
>>> var array2 = struct.f;
>>>
>>> then `array1` and `array2` would have disjoint sets of extensible
>>> properties.]
>>
>> Yes, they would. But even if they didn't, then array1 != array2, which is
>> equally odd.
>
> Both adds up to two, not one, so the counterargument is odd beats odder, and
> prohibiting expandos keeps the oddness down to == and nothing else.
What about being consistently odd? To me, 'struct.f' means allocating a new
[sic] array buffer view object. That new object thus has all of the features
you'd expect from a new object: it won't have custom properties, it will have
some default prototype, and it will not be == to any other object. Hence if
you say "struct.f.foo = 42", then "struct.f.foo" will subsequently return
undefined. No big deal - it was a new object.
>
> I'm not trying to persuade you here, just trying to agree on how to do
> "oddness accounting". It could be that we're better off with the oddness you
> prefer, for human factors reasons of some kind.
I actually think that this simply isn't going to matter. Binary data is there
for hacking with bits. Whether a struct.f, which is defined by the user to be
an array, is expandable or not isn't going to be a big deal to most people.
On the other hand, empowering users to be able to carry around typed arrays
with some extra meta-data could be useful to people.
>
> But "lost expandos" due to loss of identity are an especially nasty kind of
> bug to find.
I'm actually curious - are you aware of such bugs, and what do they actually
look like? To me this is analogous to the question of whether an API returns
to you the *same* object you passed in earlier, or a new object that is a copy
- and my vague recollection of the various APIs and SDKs that I've used over
the years is that whenever I see such issues, I make a note of them but never
find myself having to think very hard about them. And they rarely lead to
interesting bugs.
> Is there any use-case here? We've never had a bug report asking us to make
> SpiderMonkey's typed arrays extensible, AFAIK.
I was the one who brought up the use case. ;-) Say I want a matrix. I like
saying:
function makeMatrix(rows, cols) {
var result = new Float32Array(rows * cols);
result.rows = rows;
result.cols = cols;
return result;
}
I realize this is goofy - I could have created a wrapper object around the
Float32Array. But that requires more code, and I've come to enjoy doing this
kind of goofiness in scripting languages.
>
> /be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
