We just add a StrictTypeChecking attributes to WebGL functions and
modify the code generators (both JS and V8) to throw TypeError if
parameters do not match their signature types.
See http://trac.webkit.org/changeset/65689
If you want other functions also be type checked and error thrown, you
can
I think doing type checks in the bindings makes sense as a long-term strategy.
Only the bindings level can tell actually detect wrong type errors; the C++
layer can't distinguish wrong type from a validly passed null. WebGL interfaces
are not the only ones that have this problem. Here is a DOM
As I mentioned, I am not necessarily against ever changing the behavior, but
if we do, we should make sure to remove all the existing checks, as they
become an unnecessary branch. It just seems to me like that should be a
separate change than a bug due to ambiguity.
-Sam
On Thu, Aug 12, 2010 at
For what it's worth, I think this change should be made for all of the
DOM bindings, not just those for WebGL. The IDL code generators'
support for overloaded methods already generates TypeError when an
incoming argument doesn't implement any of the interfaces required by
the overloaded variants. T
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 toTyp
On Wed, Aug 11, 2010 at 10:58 PM, Darin Fisher wrote:
> On Wed, Aug 11, 2010 at 10:37 PM, Sam Weinig wrote:
>
>> On Wed, Aug 11, 2010 at 10:29 PM, Cedric Vivier wrote:
>>
>>> On Thu, Aug 12, 2010 at 13:26, Sam Weinig wrote:
>>>
For this specific case, it seems like you could easily check f
That should work too.
mo
On Thu, Aug 12, 2010 at 3:24 AM, Dumitru Daniliuc wrote:
>> so i think we just need to change toJS/toV8...
>
> sorry, i meant to(), not toJS/toV8.
>
>>
>> dumi
>>
>> On Wed, Aug 11, 2010 at 11:10 PM, Mo, Zhenyao wrote:
>>>
>>> Actually it's a different issue. What we w
>
> so i think we just need to change toJS/toV8...
sorry, i meant to(), not toJS/toV8.
>
> dumi
>
>
> On Wed, Aug 11, 2010 at 11:10 PM, Mo, Zhenyao 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, w
if converting a JS argument to the type declared in the IDL file throws an
exception, the auto-generated code will throw a TYPE_MISMATCH_ERR. so i
think we just need to change toJS/toV8 to throw exceptions when conversions
fails instead of returning NULL (toString(), toInt32(), etc. already do
that
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, M
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 wrote:
> This sounds related to the recent addition of
> [RequiresAllArguments=Raise]. Historica
On Wed, Aug 11, 2010 at 10:37 PM, Sam Weinig wrote:
> On Wed, Aug 11, 2010 at 10:29 PM, Cedric Vivier wrote:
>
>> On Thu, Aug 12, 2010 at 13:26, Sam Weinig wrote:
>>
>>> For this specific case, it seems like you could easily check for a null
>>> WebGLProgram* in WebGLRenderingContext::useProgram
On Wed, Aug 11, 2010 at 10:29 PM, Cedric Vivier wrote:
> On Thu, Aug 12, 2010 at 13:26, Sam Weinig 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 a
On Thu, Aug 12, 2010 at 13:26, Sam Weinig 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
For this specific case, it seems like you could easily check for a null
WebGLProgram* in WebGLRenderingContext::useProgram and set the
ExceptionCode.
-Sam
On Wed, Aug 11, 2010 at 8:54 PM, Mo, Zhenyao wrote:
> For example,
>
>webgl.useProgram("foo");
>
> This should throw an error. However,
For example,
webgl.useProgram("foo");
This should throw an error. However, current behavior will execute
webgl.useProgram(null)
instead, which will run through without even generating an gl error.
I saw a few TYPE_MISMATCH_ERROR in custom-binding. To me, whether
it's TYPE_MISMATCH_ER
I am not sure this is true across the board, in many places we set the
exception code to TYPE_MISMATCH_ERR on null input in the implementation (the
first one I looked at was CanvasRenderingContext2D::drawImage). Can you go
into more detail about why the WebGL bindings need to be more strict than
th
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
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
19 matches
Mail list logo
