- From: Kenneth Russell <kbr@google.com>
- Date: Tue, 3 Apr 2012 14:32:51 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Cameron McCormack <cam@mcc.id.au>, public webgl <public_webgl@khronos.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
- Message-ID: <CAMYvS2eUiPQQCDVXkH2ctZATv-bgC=y2ioPQDbOVpt4ivcEbyw@mail.gmail.com>
On Mon, Apr 2, 2012 at 5:26 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > > On 4/2/12 7:20 PM, Cameron McCormack wrote: >> >> I want to allow object with indexed properties to be passed to objects >> expecting a sequence<T> or T[] type, so that you can do for example: >> >> void f(sequence<Node> nodes); >> >> and be able to pass in a JS Array of Node objects or a NodeList. I make >> interfaces with indexed properties not distinguishable from sequences >> and arrays so that there isn't a value that would match both types. > > > Or you could make it distinguishable and check for the right interface > before trying the generic conversion. > > >> I think removing the Float32Array overload will make passing JS Arrays >> of Numbers and Float32Array objects work. > > > But require copies in the process, no? That seems highly undesirable in > this case. > > >> But note that *any* object >> that has indexed properties will be allowed to be passed here, e.g. a >> Uint8Array. If we want to disallow that, then I think that is >> incompatible with the NodeList example above. > > > Not if we place requirements on the return values of the indexed properties > or something. But that can get complicated. > > >> But if we're fine with >> Uint8Array being passed in and matching the float[] overload > > > That seems up to the WebGL folks here..... > > >> then just >> changing those types to be distinguishable, and making the argument >> resolution algorithm match the specific interface types before the >> "catch all" array/sequence types should work. > > > Indeed. My first preference would be to not have the typed array view types match the float[] overloads. The intent here was to provide convenience methods only for passing in JavaScript arrays. Supporting passing in the other view types will add a non-trivial amount of code, and might make errors less obvious to developers. (TypeError is pretty obvious.) However, if this is fundamentally incompatible with the way Web IDL is supposed to work, then my preference would be to change the argument resolution algorithm in the way you (Cameron) describe, so that the Float32Array case can at least be fast. These particular entry points aren't absolutely performance critical, but it's important to give developers a way to make their programs as fast as possible. The test case I experimented with is attached (rename to test.html). I note that Chrome throws TypeError for the two API calls and TOT WebKit allows the calls, so clearly this area needs to be clarified. Also, I have no idea what WebKit is actually doing with the incoming Uint8Array. (It may be making a JS upcall per element.) -Ken
Attachments
- text/plain attachment: test.txt
Received on Tuesday, 3 April 2012 21:33:20 UTC