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

[Mo, Zhenyao]

That should work too.

mo

On Thu, Aug 12, 2010 at 3:24 AM, Dumitru Daniliuc <dumi at chromium.org> wrote:
>> so i think we just need to change toJS/toV8...
>
> sorry, i meant to<Class>(), not toJS/toV8.
>
>>
>> dumi
>>
>> 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
>>> >>
>>> >
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>