[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Typed Array slice() renamed to subset()

On Thu, Jan 27, 2011 at 11:05 PM, Cedric Vivier <cedricv@neonux.com> wrote:
> David Sheets highlighted to me that the shim could be even less
> intrusive if added method was set not to be enumerable, so here's an
> improved shim (again) :
> function setupTypedArraySubsetCompatibilityShim() {
>        var types = [Int8Array, Uint8Array, Int16Array, Uint16Array,
> Int32Array, Uint32Array, Float32Array];
>        var original, shim;
>        for (var i = 0; i < types.length; ++i) {
>                if (types[i].prototype.slice === undefined) {
>                        original = "subset";
>                        shim = "slice";
>                } else if (types[i].prototype.subset === undefined) {
>                        original = "slice";
>                        shim = "subset";
>                }
>                Object.defineProperty(types[i].prototype, shim, { value:
> types[i].prototype[original], enumerable: false});
>        }
> }

Thanks for this and the earlier patch. I don't understand JavaScript's
prototype chain well enough. I'm relieved to see that this can be
worked around with a one-time setup.

FYI, the patch renaming Typed Arrays' slice to subset in WebKit landed
yesterday: https://bugs.webkit.org/show_bug.cgi?id=53273 .

> It's nicer but also brings to light the issue that Typed Arrays
> specification does not define any behavior regarding this.
> This leads currently to inconsistent behavior between Mozilla and
> Chrome when using the for...in construct with a typed array, Mozilla
> enumerates only its indexed properties (eg. 0 to 10 on a typed array
> of length 10) while the latter enumerate all properties (ie. also
> enumerates "length" and prototype methods).
> I think Mozilla's behavior makes more sense and propose the following
> additions to the spec :
> in 4 The ArrayBufferView Type:
> The properties "buffer", "byteOffset" and "byteLength" are
> non-enumerable as if they were created with Object.defineProperty with
> {enumerable:false}.
> in 5 The Typed Array View Types:
> The properties "BYTES_PER_ELEMENT", "length", "get", "set" and
> "subset" are non-enumerable as if they were created with
> Object.defineProperty with {enumerable:false}.

I'm very hesitant to make this spec change at this time. While I think
WebKit's IDL parser handles making properties and methods
non-enumerable, we are trying to freeze the WebGL and Typed Array
specs and implementations for 1.0, and this change has the potential
for unbounded side-effects.

Additionally, as Gregg has pointed out, using for..in syntax with
arrays is discouraged in many circles, and I suspect that loop
optimizations in JavaScript engines will work better with loops
written using integer indices. I don't want to encourage bad coding
practices by making it easy to write slow code using typed arrays.

Vlad, what do you think?


You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl