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

Re: [Public WebGL] WebGL, typed arrays, Web IDL, ECMAScript

On Tue, Oct 12, 2010 at 2:52 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> Kenneth Russell:
>> Strictly speaking, the Typed Array specification would only need
>> unsigned byte introduced since octet is already in the spec, but it
>> would be convenient if byte could be introduced as well for symmetry.
>> We found that all of the other concepts, like omittable getters and
>> setters, were already present in Web IDL.
> Yeah, perhaps I’ll rename octet to unsigned byte.
>> For WebGL in general, one of the recent sticking points has been the
>> different handling of wrong numbers of arguments to function calls
>> between Web IDL and ECMAScript. In pure ECMAScript, if too few
>> arguments are passed to a function, "undefined" is passed for the
>> remaining arguments. In some browsers' scripting engines an exception
>> is thrown when a function on a host object is called with too few
>> arguments; in some, the ECMAScript behavior is taken. I think the Web
>> IDL spec is a little ambiguous on this topic, in particular for
>> non-overloaded functions; correct me if I'm wrong.
> I think for non-overloaded functions (as well as overloaded ones with
> too few arguments) it is defined to throw a TypeError, rather than
> assume undefined.  The overload resolution algorithm
> http://dev.w3.org/2006/webapi/WebIDL/#dfn-overload-resolution-algorithm
> will start off with the single operation with a certain argument type
> list length, and then step 2 will result in the set becoming empty if
> the number of arguments passed wasn’t exactly that number.

I see. Thanks for pointing this out. I should have realized this was
the behavior given the presence of optional arguments in the spec.

> It’s still an open issue whether that, or assuming undefined, is the
> behaviour we want to end up with.
> Overloading in Web IDL is well defined, but kind of a mess at the
> moment, and subject to change.

Understood. Seems like a difficult decision. I think that the current
behavior of requiring the number of arguments to match maintains the
best parity among different language bindings, though it's different
behavior than pure ECMAScript.

>> Note also that we are thinking of adding support for read-only Typed
>> Array views to better handle the use case of XMLHttpRequest, which
>> will involve some refactoring of the type hierarchy but not change it
>> substantially. We have also been thinking about adding a couple of
>> methods and postMessage() semantics to help send data to web workers
>> and back.
> OK, so in your view typed arrays are the way forward for array types in
> Web APIs in general?

See other thread.


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: