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 <zhen...@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 <aba...@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 <zhen...@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@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev