That should work too. mo
On Thu, Aug 12, 2010 at 3:24 AM, Dumitru Daniliuc <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> >> [email protected] >>> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> >>> > >>> _______________________________________________ >>> webkit-dev mailing list >>> [email protected] >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
