Hardly. Right now we already do the type checking in the generated toType(argument) functions. Instead of casting to null, we throw a TypeError, which adds no extra cost if the type is correct.
Besides, where I looked, after toType(argument) call, exception is checked. Only that currently toType(argument) is not generating exceptions. Mo On Thu, Aug 12, 2010 at 9:20 AM, Sam Weinig <[email protected]> wrote: > > > On Wed, Aug 11, 2010 at 10:58 PM, Darin Fisher <[email protected]> wrote: >> >> On Wed, Aug 11, 2010 at 10:37 PM, Sam Weinig <[email protected]> wrote: >>> >>> On Wed, Aug 11, 2010 at 10:29 PM, Cedric Vivier <[email protected]> >>> wrote: >>>> >>>> On Thu, Aug 12, 2010 at 13:26, Sam Weinig <[email protected]> wrote: >>>>> >>>>> For this specific case, it seems like you could easily check for a null >>>>> WebGLProgram* in WebGLRenderingContext::useProgram and set the >>>>> ExceptionCode. >>>> >>>> Nope, null is a valid argument, it bounds to the initial program, which >>>> means nothing will be drawn with WebGL. >>>> Certainly not the expected behavior when one pass the wrong type to the >>>> argument like Zhenyao pointed out, therefore throwing TypeError really >>>> makes >>>> sense here (and elsewhere with WebGL API). >>> >>> Ok, in that case, it seems like you need to do it in the bindings for >>> this. I would prefer not making a sweeping change at this time, and instead >>> keeping the changes just to places where the extra checking is necessary due >>> to ambiguity (as in this useProgram case). >>> -Sam >> >> Out of curiosity, if we have the ability for code to be auto generated >> from the IDL, why not use it universally? I'm trying to guess to understand >> your preference :) >> -Darin > > My concern with doing it universally is the performance cost of doing the > check twice in many places (once in the bindings and once in the > implementation with a null check). We could certainly re-evaluate the way we > do these type checks, potentially even converting the existing null checks > in the implementation to asserts, but I think that discussion shouldn't be > conflated with this bug fix. > -Sam > _______________________________________________ > 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
