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

Mo, Zhenyao zhenyao at gmail.com
Wed Aug 11 23:13:30 PDT 2010

The auto-generated code will look like

   If (argument.isUndefinedOrNull() == false && toType(argument) == null)

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

More information about the webkit-dev mailing list