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

[Mo, Zhenyao]

The auto-generated code will look like

   If (argument.isUndefinedOrNull() == false && toType(argument) == null)
       raise(TypeError);

I really think we should do this universally.  However, if there is a
good reason we really shouldn't, please let us know.

On Wed, Aug 11, 2010 at 11:10 PM, Mo, Zhenyao <zhenyao at gmail.com> wrote:
> Actually it's a different issue.  What we want to do is not enforcing
> full arguments, but if an input argument is the wrong type, we raise a
> TypeError.
>
> Mo
>
> On Wed, Aug 11, 2010 at 7:13 PM, Adam Barth <abarth at webkit.org> wrote:
>> This sounds related to the recent addition of
>> [RequiresAllArguments=Raise].  Historically, we've been lax about
>> missing arguments.  I think the specs want us to be stricter, but last
>> time we discussed the topic, the read I got was that the compatibility
>> pain might not be worth the benefit.
>>
>> Adam
>>
>>
>> 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
>>>
>>
>