[webkit-dev] js binding: function argument type checking

[Mo, Zhenyao]

For example,

    webgl.useProgram("foo");

This should throw an error.  However, current behavior will execute

    webgl.useProgram(null)

instead, which will run through without even generating an gl error.

I saw a few TYPE_MISMATCH_ERROR in custom-binding.  To me, whether
it's TYPE_MISMATCH_ERROR or TypeError is less important, but
generating an error is.

On Wed, Aug 11, 2010 at 8:14 PM, Sam Weinig <sam.weinig at gmail.com> wrote:
> I am not sure this is true across the board, in many places we set the
> exception code to TYPE_MISMATCH_ERR on null input in the implementation (the
> first one I looked at was CanvasRenderingContext2D::drawImage). Can you go
> into more detail about why the WebGL bindings need to be more strict than
> the rest of the codebase?
> -Sam
>
> On Wed, Aug 11, 2010 at 7:06 PM, Mo, Zhenyao <zhenyao at gmail.com> wrote:
>>
>> Currently for a function's signature in WebKit, if an argument's type
>> is a wrapper type (those JS objec ts that wrap c++ objects, for
>> example, JSWebGLProgram, JSCSSRule, etc.) and if the input object's
>> type does not match the signature, the input is casted to null and no
>> TypeError is raised.
>>
>> Even though WebKit doesn't use Web IDL specially, I think we can look
>> to the Web IDL spec for guidance on what the behavior should be.
>> According to Web IDL spec (http://dev.w3.org/2006/webapi/WebIDL/),
>> unless [AllowAny] is put in the signature, an TypeError should be
>> raised if an argument type does not match its signature.  The new
>> automatic code generation for overloaded functions in WebKit DOES
>> raise TypeError when it fails to determine which overloaded variant to
>> call.
>>
>> We definitely need to do the strict type checking for WebGL functions.
>>  However, changing the default behavior of the IDL code generators
>> might have a significant compatibility impact. It isn't clear to us
>> whether the current behavior is intentional.  If yes, please let us
>> know and we will try to fix the WebGL part only.  Otherwise we will
>> modify the general rule instead.
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>