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

Sam Weinig sam.weinig at gmail.com
Thu Aug 12 09:20:26 PDT 2010


On Wed, Aug 11, 2010 at 10:58 PM, Darin Fisher <darin at chromium.org> wrote:

> On Wed, Aug 11, 2010 at 10:37 PM, Sam Weinig <sam.weinig at gmail.com> wrote:
>
>> On Wed, Aug 11, 2010 at 10:29 PM, Cedric Vivier <cedricv at neonux.com>wrote:
>>
>>> On Thu, Aug 12, 2010 at 13:26, Sam Weinig <sam.weinig at gmail.com> wrote:
>>>
>>>> For this specific case, it seems like you could easily check for a null
>>>> WebGLProgram* in WebGLRenderingContext::useProgram and set the
>>>> ExceptionCode.
>>>
>>>
>>> Nope, null is a valid argument, it bounds to the initial program, which
>>> means nothing will be drawn with WebGL.
>>> Certainly not the expected behavior when one pass the wrong type to the
>>> argument like Zhenyao pointed out, therefore throwing TypeError really makes
>>> sense here (and elsewhere with WebGL API).
>>>
>>>
>> Ok, in that case, it seems like you need to do it in the bindings for
>> this. I would prefer not making a sweeping change at this time, and instead
>> keeping the changes just to places where the extra checking is necessary due
>> to ambiguity (as in this useProgram case).
>>
>> -Sam
>>
>>
> Out of curiosity, if we have the ability for code to be auto generated from
> the IDL, why not use it universally?  I'm trying to guess to understand your
> preference :)
>
> -Darin
>

My concern with doing it universally is the performance cost of doing the
check twice in many places (once in the bindings and once in the
implementation with a null check). We could certainly re-evaluate the way we
do these type checks, potentially even converting the existing null checks
in the implementation to asserts, but I think that discussion shouldn't be
conflated with this bug fix.

-Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100812/69c48343/attachment.html>


More information about the webkit-dev mailing list