Re: [webkit-dev] Optional parameter in IDL and undefined JS value
Kenneth pointed out that NaN should then be converted to 0 per ECMA. So we're doing the right thing in our code generators. Since File API has been updated to get this issue clarified, we're fine here with nothing particular that needs to be done. Thanks for all your help. On Mon, Apr 25, 2011 at 4:43 PM, Jian Li jia...@chromium.org wrote: Please see inline for the reply from the spec author Arun about your questions. Arun has updated Blob.slice in the File API spec to explicitly illustrate the case for optional end parameter. If the optional end parameter is not used as a parameter when making this call, let relativeEnd be size. For undefined value being passed to optional numeric parameter, should we consider following ECMA-262 (referred from Web IDL) that defines the conversion of undefined to NaN (see Table 12 in Section 9.3)? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
Please see inline for the reply from the spec author Arun about your questions. Arun has updated Blob.slice in the File API spec to explicitly illustrate the case for optional end parameter. If the optional end parameter is not used as a parameter when making this call, let relativeEnd be size. For undefined value being passed to optional numeric parameter, should we consider following ECMA-262 (referred from Web IDL) that defines the conversion of undefined to NaN (see Table 12 in Section 9.3)? On Fri, Apr 22, 2011 at 3:00 PM, Geoffrey Garen gga...@apple.com wrote: I would suggest updating the specification for Blob.slice() so that it doesn't expect passing undefined for the second argument to have identical behavior to not passing the argument at all. The subarray method in the Typed Array spec [1], which has similar behavior to slice(), doesn't mention the undefined value. I am afraid that this suggested change might not be preferred since we're trying to mimic the behavior of Blob.slice to Array.slice and Array.slice does allow passing undefined and treat it as omitting the value. Jian, Can you clarify why we want Blob.slice to mimic Array.prototype.slice in this strange argument quirk? Let me suggest three reasons why we don't want Blob.slice to mimic Array.prototype.slice in this strange argument quirk: 1. Legacy argument quirks exist for legacy compatibility and nothing else. Since Blobs have no legacy requirements, they should not re-introduce the mistakes of JavaScript past. There are many legacy argument quirks in JavaScript. They often confuse programmers, rather than enabling them. For example, new Array(x) creates an array with ToInteger(x) elements in it, while new Array(x, y) creates an array with 2 elements in it, x and y. Would you mimic that quirk in Blobs if you could? (From Arun): Can't argue with his intent in saying this :-). But, WebIDL takes care of any calls that ECMA-262 makes w.r.t. numerical arguments (e.g. there is a ToNumber call presumed for long long arguments), *and* we can't really do calls of the sort new Blob(x). Rather, we go via Blob.slice( ) or BlobBuilder calls.g 2. A Blob is not an Array. Blobs are incompatible with all other Array semantics. They don't have a length property. They don't support bracket access. They don't support destructive modification. If Blobs were like Arrays, you could just use Array.prototype.slice to slice a Blob. But you can't, because they're not alike at all. (From Arun): Blobs are more like Strings -- so I agree with the above. In fact, I'm worried about our use of some Array semantics w.r.t. Blob.slice, but I'm reassured by the fact that byte-order semantics for the start argument to a Blob.slice call matches character-order semantics for the start argument to a String.slice call. I wonder if there are any other gotchas here? 3. Your specification doesn't actually conform to the exact semantics of all the argument quirks of Array.prototype.slice. There are a number of other quirks that you have left out because they are strange and you are not familiar with them. I will leave it as a thought experiment for you to go and find all the other quirks of Array.prototype.slice that you have missed. While you are seeking them out, you can meditate on whether you are making your API better or worse. (From Arun): Hah! He makes the point strongly here, but he isn't wrong. I've spent a while reading ECMA-262. Honestly, Blob is the first host object that introduces a slice method (to the best of my knowledge) and WebIDL constructs aren't too close to ECMA-262 constructs. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
An alternative would be to generate code for optional args along the lines of (pseudo code): void foo(Arg1Type arg1, [Optional] Arg2Type arg2); = Arg1Type arg1 = toArg1Type(arguments[0]); if (arguments.length 2) return impl-foo(arg1); Arg2Type arg2 = toArg2Type(arguments[1]); return impl-foo(arg1, arg2); This would allow the C++ impl to use overloading to resolve things correctly. --Oliver On Apr 21, 2011, at 10:16 PM, Jian Li wrote: One other way is to write custom binding code to handle this case specially. On Thu, Apr 21, 2011 at 10:07 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 21, 2011, at 6:29 PM, Jian Li wrote: I've pinged the spec author to make it clear in the spec. What is meant in the spec is really that we want Blob.slice to have the same exact behavior as Array.slice defined in ECMAScript 5, 15.4.4.10. That is, Blob.slice(start) has the same result as Blob.slice(start, undefined). The current code generator scripts will convert undefined value to 0. But we really want to use the custom default value for Blob.slice. Do we want to consider adding DefaultValue= extended attribute support to IDL? I'd prefer if we can find a way to solve it that does not require diverging our IDL dialect further from Web IDL, especially since this is the only method likely to need the feature. Are there any other practical solutions? Regards, Maciej Thanks, Jian On Thu, Apr 21, 2011 at 3:38 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 21, 2011, at 12:14 AM, Jian Li wrote: The current File API spec says that: If the end parameter is not provided (undefined), let relativeEnd be size. That seems like loose wording. Parameter not provided and parameter provided with a value of undefined are in general not the same thing. The spec should be explicit about which cases it's talking about. Regards, Maciej ___ 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
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
This seems not to work. When we call foo(arg1, undefined), arguments.length is 2 and thus we convert undefined to 0 and pass it to impl-foo(arg1, arg2). But we want default value for arg2 other than 0. On Fri, Apr 22, 2011 at 8:52 AM, Oliver Hunt oli...@apple.com wrote: An alternative would be to generate code for optional args along the lines of (pseudo code): void foo(Arg1Type arg1, [Optional] Arg2Type arg2); = Arg1Type arg1 = toArg1Type(arguments[0]); if (arguments.length 2) return impl-foo(arg1); Arg2Type arg2 = toArg2Type(arguments[1]); return impl-foo(arg1, arg2); This would allow the C++ impl to use overloading to resolve things correctly. --Oliver On Apr 21, 2011, at 10:16 PM, Jian Li wrote: One other way is to write custom binding code to handle this case specially. On Thu, Apr 21, 2011 at 10:07 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 21, 2011, at 6:29 PM, Jian Li wrote: I've pinged the spec author to make it clear in the spec. What is meant in the spec is really that we want Blob.slice to have the same exact behavior as Array.slice defined in ECMAScript 5, 15.4.4.10. That is, Blob.slice(start) has the same result as Blob.slice(start, undefined). The current code generator scripts will convert undefined value to 0. But we really want to use the custom default value for Blob.slice. Do we want to consider adding DefaultValue= extended attribute support to IDL? I'd prefer if we can find a way to solve it that does not require diverging our IDL dialect further from Web IDL, especially since this is the only method likely to need the feature. Are there any other practical solutions? Regards, Maciej Thanks, Jian On Thu, Apr 21, 2011 at 3:38 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 21, 2011, at 12:14 AM, Jian Li wrote: The current File API spec says that: If the end parameter is not provided (undefined), let relativeEnd be size. That seems like loose wording. Parameter not provided and parameter provided with a value of undefined are in general not the same thing. The spec should be explicit about which cases it's talking about. Regards, Maciej ___ 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
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
On Fri, Apr 22, 2011 at 12:21 PM, Kenneth Russell k...@google.com wrote: The generated code for optional arguments in WebKit IDL already does this sort of dispatch. See Jian Li's first message on this thread and the code snippet he cited. The problem is that undefined is being passed explicitly as the second argument. If this weren't being done, the default value for the argument defined by the C++ header would be used correctly. I would suggest updating the specification for Blob.slice() so that it doesn't expect passing undefined for the second argument to have identical behavior to not passing the argument at all. The subarray method in the Typed Array spec [1], which has similar behavior to slice(), doesn't mention the undefined value. I am afraid that this suggested change might not be preferred since we're trying to mimic the behavior of Blob.slice to Array.slice and Array.slice does allow passing undefined and treat it as omitting the value. -Ken [1] http://www.khronos.org/registry/typedarray/specs/latest/#7 On Fri, Apr 22, 2011 at 10:01 AM, Jian Li jia...@chromium.org wrote: This seems not to work. When we call foo(arg1, undefined), arguments.length is 2 and thus we convert undefined to 0 and pass it to impl-foo(arg1, arg2). But we want default value for arg2 other than 0. On Fri, Apr 22, 2011 at 8:52 AM, Oliver Hunt oli...@apple.com wrote: An alternative would be to generate code for optional args along the lines of (pseudo code): void foo(Arg1Type arg1, [Optional] Arg2Type arg2); = Arg1Type arg1 = toArg1Type(arguments[0]); if (arguments.length 2) return impl-foo(arg1); Arg2Type arg2 = toArg2Type(arguments[1]); return impl-foo(arg1, arg2); This would allow the C++ impl to use overloading to resolve things correctly. --Oliver On Apr 21, 2011, at 10:16 PM, Jian Li wrote: One other way is to write custom binding code to handle this case specially. On Thu, Apr 21, 2011 at 10:07 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 21, 2011, at 6:29 PM, Jian Li wrote: I've pinged the spec author to make it clear in the spec. What is meant in the spec is really that we want Blob.slice to have the same exact behavior as Array.slice defined in ECMAScript 5, 15.4.4.10. That is, Blob.slice(start) has the same result as Blob.slice(start, undefined). The current code generator scripts will convert undefined value to 0. But we really want to use the custom default value for Blob.slice. Do we want to consider adding DefaultValue= extended attribute support to IDL? I'd prefer if we can find a way to solve it that does not require diverging our IDL dialect further from Web IDL, especially since this is the only method likely to need the feature. Are there any other practical solutions? Regards, Maciej Thanks, Jian On Thu, Apr 21, 2011 at 3:38 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 21, 2011, at 12:14 AM, Jian Li wrote: The current File API spec says that: If the end parameter is not provided (undefined), let relativeEnd be size. That seems like loose wording. Parameter not provided and parameter provided with a value of undefined are in general not the same thing. The spec should be explicit about which cases it's talking about. Regards, Maciej ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
I would suggest updating the specification for Blob.slice() so that it doesn't expect passing undefined for the second argument to have identical behavior to not passing the argument at all. The subarray method in the Typed Array spec [1], which has similar behavior to slice(), doesn't mention the undefined value. I am afraid that this suggested change might not be preferred since we're trying to mimic the behavior of Blob.slice to Array.slice and Array.slice does allow passing undefined and treat it as omitting the value. Jian, Can you clarify why we want Blob.slice to mimic Array.prototype.slice in this strange argument quirk? Let me suggest three reasons why we don't want Blob.slice to mimic Array.prototype.slice in this strange argument quirk: 1. Legacy argument quirks exist for legacy compatibility and nothing else. Since Blobs have no legacy requirements, they should not re-introduce the mistakes of JavaScript past. There are many legacy argument quirks in JavaScript. They often confuse programmers, rather than enabling them. For example, new Array(x) creates an array with ToInteger(x) elements in it, while new Array(x, y) creates an array with 2 elements in it, x and y. Would you mimic that quirk in Blobs if you could? 2. A Blob is not an Array. Blobs are incompatible with all other Array semantics. They don't have a length property. They don't support bracket access. They don't support destructive modification. If Blobs were like Arrays, you could just use Array.prototype.slice to slice a Blob. But you can't, because they're not alike at all. 3. Your specification doesn't actually conform to the exact semantics of all the argument quirks of Array.prototype.slice. There are a number of other quirks that you have left out because they are strange and you are not familiar with them. I will leave it as a thought experiment for you to go and find all the other quirks of Array.prototype.slice that you have missed. While you are seeking them out, you can meditate on whether you are making your API better or worse. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
Jian Li: I am referring to Blob.slice(start, end) that mimics Array.slice. Where in WebIDL has this behavior defined? Sorry I can't find it in the spec. For Array.slice(start, end), both Safari and Chrome treat passing undefined as omitted parameter, while Firefox and IE treat passing undefined as 0. Ryosuke Niwa: Doesn't that mean the current behavior (i.e. treating undefined as 0) is correct since that's what other browsers do? The File API spec currently says: Blob slice(in optional long long start, in optional long long end, in optional DOMString contentType); and Web IDL says that if you call blob.slice(10, undefined); then this is calling the function with two arguments, where the second argument will be converted to 0 due to how the conversion of JS undefined to an IDL long long value is defined. This is not the same as calling blob.slice(10); Whenever some optional arguments are omitted, the prose for the definition of the operation defines what that means; it’s not automatically “convert from undefined”. There is no way in Web IDL to state that when undefined is passed as an argument explicitly that it is handled differently from the rules in http://dev.w3.org/2006/webapi/WebIDL/#es-type-mapping (although the authors of the File API spec could include this additional requirement in prose, overriding Web IDL, if they wanted). -- Cameron McCormack ≝ http://mcc.id.au/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
The current File API spec says that: If the end parameter is not provided (undefined), let relativeEnd be size. This seems to indicate that passing undefined as end parameter is same as omitting it. Per the latest discussion on public-webapps, we're in the process of making it be more like Array.slice. I will also ping the spec author about this issue. Unfortunately we have inconsistency between Array.slice and other DOM methods, in terms of handling undefined parameter value in WebKit. We also have inconsistency among different browser vendors for interpreting Array.slice(start, undefined). On Wed, Apr 20, 2011 at 11:17 PM, Cameron McCormack c...@mcc.id.au wrote: Jian Li: I am referring to Blob.slice(start, end) that mimics Array.slice. Where in WebIDL has this behavior defined? Sorry I can't find it in the spec. For Array.slice(start, end), both Safari and Chrome treat passing undefined as omitted parameter, while Firefox and IE treat passing undefined as 0. Ryosuke Niwa: Doesn't that mean the current behavior (i.e. treating undefined as 0) is correct since that's what other browsers do? The File API spec currently says: Blob slice(in optional long long start, in optional long long end, in optional DOMString contentType); and Web IDL says that if you call blob.slice(10, undefined); then this is calling the function with two arguments, where the second argument will be converted to 0 due to how the conversion of JS undefined to an IDL long long value is defined. This is not the same as calling blob.slice(10); Whenever some optional arguments are omitted, the prose for the definition of the operation defines what that means; it’s not automatically “convert from undefined”. There is no way in Web IDL to state that when undefined is passed as an argument explicitly that it is handled differently from the rules in http://dev.w3.org/2006/webapi/WebIDL/#es-type-mapping (although the authors of the File API spec could include this additional requirement in prose, overriding Web IDL, if they wanted). -- Cameron McCormack ≝ http://mcc.id.au/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
It seems that we're doing the right thing for Array.slice in WebKit in order to be consistent with ECMAScript 5, 15.4.4.10. Since Blob.slice in File API is following the same route, we probably want to fix the handling in Blob.slice and keep other DOM methods as they're now. On Thu, Apr 21, 2011 at 12:14 AM, Jian Li jia...@chromium.org wrote: The current File API spec says that: If the end parameter is not provided (undefined), let relativeEnd be size. This seems to indicate that passing undefined as end parameter is same as omitting it. Per the latest discussion on public-webapps, we're in the process of making it be more like Array.slice. I will also ping the spec author about this issue. Unfortunately we have inconsistency between Array.slice and other DOM methods, in terms of handling undefined parameter value in WebKit. We also have inconsistency among different browser vendors for interpreting Array.slice(start, undefined). On Wed, Apr 20, 2011 at 11:17 PM, Cameron McCormack c...@mcc.id.au wrote: Jian Li: I am referring to Blob.slice(start, end) that mimics Array.slice. Where in WebIDL has this behavior defined? Sorry I can't find it in the spec. For Array.slice(start, end), both Safari and Chrome treat passing undefined as omitted parameter, while Firefox and IE treat passing undefined as 0. Ryosuke Niwa: Doesn't that mean the current behavior (i.e. treating undefined as 0) is correct since that's what other browsers do? The File API spec currently says: Blob slice(in optional long long start, in optional long long end, in optional DOMString contentType); and Web IDL says that if you call blob.slice(10, undefined); then this is calling the function with two arguments, where the second argument will be converted to 0 due to how the conversion of JS undefined to an IDL long long value is defined. This is not the same as calling blob.slice(10); Whenever some optional arguments are omitted, the prose for the definition of the operation defines what that means; it’s not automatically “convert from undefined”. There is no way in Web IDL to state that when undefined is passed as an argument explicitly that it is handled differently from the rules in http://dev.w3.org/2006/webapi/WebIDL/#es-type-mapping (although the authors of the File API spec could include this additional requirement in prose, overriding Web IDL, if they wanted). -- Cameron McCormack ≝ http://mcc.id.au/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
On Apr 21, 2011, at 12:14 AM, Jian Li wrote: The current File API spec says that: If the end parameter is not provided (undefined), let relativeEnd be size. That seems like loose wording. Parameter not provided and parameter provided with a value of undefined are in general not the same thing. The spec should be explicit about which cases it's talking about. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
I've pinged the spec author to make it clear in the spec. What is meant in the spec is really that we want Blob.slice to have the same exact behavior as Array.slice defined in ECMAScript 5, 15.4.4.10. That is, Blob.slice(start) has the same result as Blob.slice(start, undefined). The current code generator scripts will convert undefined value to 0. But we really want to use the custom default value for Blob.slice. Do we want to consider adding DefaultValue= extended attribute support to IDL? Thanks, Jian On Thu, Apr 21, 2011 at 3:38 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 21, 2011, at 12:14 AM, Jian Li wrote: The current File API spec says that: If the end parameter is not provided (undefined), let relativeEnd be size. That seems like loose wording. Parameter not provided and parameter provided with a value of undefined are in general not the same thing. The spec should be explicit about which cases it's talking about. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
On Apr 21, 2011, at 6:29 PM, Jian Li wrote: I've pinged the spec author to make it clear in the spec. What is meant in the spec is really that we want Blob.slice to have the same exact behavior as Array.slice defined in ECMAScript 5, 15.4.4.10. That is, Blob.slice(start) has the same result as Blob.slice(start, undefined). The current code generator scripts will convert undefined value to 0. But we really want to use the custom default value for Blob.slice. Do we want to consider adding DefaultValue= extended attribute support to IDL? I'd prefer if we can find a way to solve it that does not require diverging our IDL dialect further from Web IDL, especially since this is the only method likely to need the feature. Are there any other practical solutions? Regards, Maciej Thanks, Jian On Thu, Apr 21, 2011 at 3:38 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 21, 2011, at 12:14 AM, Jian Li wrote: The current File API spec says that: If the end parameter is not provided (undefined), let relativeEnd be size. That seems like loose wording. Parameter not provided and parameter provided with a value of undefined are in general not the same thing. The spec should be explicit about which cases it's talking about. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
One other way is to write custom binding code to handle this case specially. On Thu, Apr 21, 2011 at 10:07 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 21, 2011, at 6:29 PM, Jian Li wrote: I've pinged the spec author to make it clear in the spec. What is meant in the spec is really that we want Blob.slice to have the same exact behavior as Array.slice defined in ECMAScript 5, 15.4.4.10. That is, Blob.slice(start) has the same result as Blob.slice(start, undefined). The current code generator scripts will convert undefined value to 0. But we really want to use the custom default value for Blob.slice. Do we want to consider adding DefaultValue= extended attribute support to IDL? I'd prefer if we can find a way to solve it that does not require diverging our IDL dialect further from Web IDL, especially since this is the only method likely to need the feature. Are there any other practical solutions? Regards, Maciej Thanks, Jian On Thu, Apr 21, 2011 at 3:38 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 21, 2011, at 12:14 AM, Jian Li wrote: The current File API spec says that: If the end parameter is not provided (undefined), let relativeEnd be size. That seems like loose wording. Parameter not provided and parameter provided with a value of undefined are in general not the same thing. The spec should be explicit about which cases it's talking about. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Optional parameter in IDL and undefined JS value
Hi,
I've just found a problem in our generated code for handling optional
parameters. Suppose we define a method with optional parameter in numeric
type, like the following in IDL:
Foo bar(in [Optional] long long start, in [Optional] long long
end);
And we declare our C++ method as the following. Note that the default value
of the 2nd parameter is not 0.
PassRefPtrFoo bar(long long start = 0, long long end =
std::numeric_limitslong long::max());
If we call the JS method with only 1 parameter, everything works as
expected. However, if we call the JS method with 2 parameters and pass
'undefined' as the 2nd parameter, we trigger the problem.
By looking into the generated JSC code below, I found out that we are
converting undefined JS value to 0 and pass it to the function. As the
result, the default parameter value in the declaration is not respected.
EncodedJSValue JSC_HOST_CALL jsFooPrototypeFunctionFoo(ExecState* exec)
{
JSValue thisValue = exec-hostThisValue();
if (!thisValue.inherits(JSFoo::s_info))
return throwVMTypeError(exec);
JSFoo* castedThis = static_castJSFoo*(asObject(thisValue));
Foo* imp = static_castFoo*(castedThis-impl());
int argsCount = exec-argumentCount();
if (argsCount = 0) {
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar()));
return JSValue::encode(result);
}
long long start(static_castlong
long(exec-argument(0).toInteger(exec)));
if (exec-hadException())
return JSValue::encode(jsUndefined());
if (argsCount = 1) {
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar(start)));
return JSValue::encode(result);
}
long long end(static_castlong
long(exec-argument(1).toInteger(exec)));
if (exec-hadException())
return JSValue::encode(jsUndefined());
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar(start, end)));
return JSValue::encode(result);
}
One solution is to add the default value support in IDL. For example, we can
change the above definition of bar to something like:
Foo bar(in [Optional, DefaultValue=0] long long start, in
[Optional, DefaultValue=2147483647] long long end);
Or the other way is to add a bool parameter for each optional parameter in
the class method declaration, that is used to indicate if the passing
parameter is defined or not. This would involve the change to both code
generator scripts and the existing implementations.
How do you think? Personally I like the 1st approach since it is simpler.
Thanks,
Jian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
On Apr 20, 2011, at 6:16 PM, Jian Li wrote:
Hi,
I've just found a problem in our generated code for handling optional
parameters. Suppose we define a method with optional parameter in numeric
type, like the following in IDL:
Foo bar(in [Optional] long long start, in [Optional] long long end);
And we declare our C++ method as the following. Note that the default value
of the 2nd parameter is not 0.
PassRefPtrFoo bar(long long start = 0, long long end =
std::numeric_limitslong long::max());
If we call the JS method with only 1 parameter, everything works as expected.
However, if we call the JS method with 2 parameters and pass 'undefined' as
the 2nd parameter, we trigger the problem.
Is it actually a bug that explicitly passing undefined acts like passing 0,
instead of like an omitted parameter? I think it's correct per Web IDL. What's
the specific case where this is a problem?
Regards,
Maciej
By looking into the generated JSC code below, I found out that we are
converting undefined JS value to 0 and pass it to the function. As the
result, the default parameter value in the declaration is not respected.
EncodedJSValue JSC_HOST_CALL jsFooPrototypeFunctionFoo(ExecState* exec)
{
JSValue thisValue = exec-hostThisValue();
if (!thisValue.inherits(JSFoo::s_info))
return throwVMTypeError(exec);
JSFoo* castedThis = static_castJSFoo*(asObject(thisValue));
Foo* imp = static_castFoo*(castedThis-impl());
int argsCount = exec-argumentCount();
if (argsCount = 0) {
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar()));
return JSValue::encode(result);
}
long long start(static_castlong
long(exec-argument(0).toInteger(exec)));
if (exec-hadException())
return JSValue::encode(jsUndefined());
if (argsCount = 1) {
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar(start)));
return JSValue::encode(result);
}
long long end(static_castlong long(exec-argument(1).toInteger(exec)));
if (exec-hadException())
return JSValue::encode(jsUndefined());
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar(start, end)));
return JSValue::encode(result);
}
One solution is to add the default value support in IDL. For example, we can
change the above definition of bar to something like:
Foo bar(in [Optional, DefaultValue=0] long long start, in [Optional,
DefaultValue=2147483647] long long end);
Or the other way is to add a bool parameter for each optional parameter in
the class method declaration, that is used to indicate if the passing
parameter is defined or not. This would involve the change to both code
generator scripts and the existing implementations.
How do you think? Personally I like the 1st approach since it is simpler.
Thanks,
Jian
___
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
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
I am referring to Blob.slice(start, end) that mimics Array.slice. Where in
WebIDL has this behavior defined? Sorry I can't find it in the spec.
For Array.slice(start, end), both Safari and Chrome treat passing undefined
as omitted parameter, while Firefox and IE treat passing undefined as 0. If
it is true that passing undefined should be treated as 0, we do not have a
bug in JSC and V8 bindings layer. However, we do have a bug in JSC and V8
internals.
On Wed, Apr 20, 2011 at 7:28 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 20, 2011, at 6:16 PM, Jian Li wrote:
Hi,
I've just found a problem in our generated code for handling optional
parameters. Suppose we define a method with optional parameter in numeric
type, like the following in IDL:
Foo bar(in [Optional] long long start, in [Optional] long long
end);
And we declare our C++ method as the following. Note that the default value
of the 2nd parameter is not 0.
PassRefPtrFoo bar(long long start = 0, long long end =
std::numeric_limitslong long::max());
If we call the JS method with only 1 parameter, everything works as
expected. However, if we call the JS method with 2 parameters and pass
'undefined' as the 2nd parameter, we trigger the problem.
Is it actually a bug that explicitly passing undefined acts like passing 0,
instead of like an omitted parameter? I think it's correct per Web IDL.
What's the specific case where this is a problem?
Regards,
Maciej
By looking into the generated JSC code below, I found out that we are
converting undefined JS value to 0 and pass it to the function. As the
result, the default parameter value in the declaration is not respected.
EncodedJSValue JSC_HOST_CALL jsFooPrototypeFunctionFoo(ExecState* exec)
{
JSValue thisValue = exec-hostThisValue();
if (!thisValue.inherits(JSFoo::s_info))
return throwVMTypeError(exec);
JSFoo* castedThis = static_castJSFoo*(asObject(thisValue));
Foo* imp = static_castFoo*(castedThis-impl());
int argsCount = exec-argumentCount();
if (argsCount = 0) {
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar()));
return JSValue::encode(result);
}
long long start(static_castlong
long(exec-argument(0).toInteger(exec)));
if (exec-hadException())
return JSValue::encode(jsUndefined());
if (argsCount = 1) {
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar(start)));
return JSValue::encode(result);
}
long long end(static_castlong
long(exec-argument(1).toInteger(exec)));
if (exec-hadException())
return JSValue::encode(jsUndefined());
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar(start, end)));
return JSValue::encode(result);
}
One solution is to add the default value support in IDL. For example, we
can change the above definition of bar to something like:
Foo bar(in [Optional, DefaultValue=0] long long start, in
[Optional, DefaultValue=2147483647] long long end);
Or the other way is to add a bool parameter for each optional parameter in
the class method declaration, that is used to indicate if the passing
parameter is defined or not. This would involve the change to both code
generator scripts and the existing implementations.
How do you think? Personally I like the 1st approach since it is simpler.
Thanks,
Jian
___
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
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
On Wed, Apr 20, 2011 at 9:58 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Apr 20, 2011 at 9:37 PM, Jian Li jia...@chromium.org wrote: I am referring to Blob.slice(start, end) that mimics Array.slice. Where in WebIDL has this behavior defined? Sorry I can't find it in the spec. For Array.slice(start, end), both Safari and Chrome treat passing undefined as omitted parameter, while Firefox and IE treat passing undefined as 0. Doesn't that mean the current behavior (i.e. treating undefined as 0) is correct since that's what other browsers do? If it is true that passing undefined should be treated as 0, we do not have a bug in JSC and V8 bindings layer. However, we do have a bug in JSC and V8 internals. I don't get what you mean here. If there are no bugs in JSC/V8 bindings, then what are you trying to fix? I mean we need to fix Array.slice behavior in JSC and V8 since Array.slice is not defined in our IDL. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
Just my two cents.
There is an elaborate specification how Array.prototype.slice should
treat undefined parameters, see ECMAScript 5, 15.4.4.10. Please, note
that the spec treats undefined start and end differently: start is
converted with ToInteger which turns undefined into 0, while end is
treated as len if it's undefined.
Alas, we don't have such an elaborate spec for DOM methods. I
personally find different behaviour of foo() vs. foo(undefined)
somewhat counterintuitive, but technically one can use
arguments.length to implement such a dispatch in pure JS, so IMHO it's
fine (cf. though with Array.slice which doesn't use arguments.length
and AFAIK no other functions in ECMAScript, at least not one for
arrays.)
yours,
anton.
On Wed, Apr 20, 2011 at 9:37 PM, Jian Li jia...@chromium.org wrote:
I am referring to Blob.slice(start, end) that mimics Array.slice. Where in
WebIDL has this behavior defined? Sorry I can't find it in the spec.
For Array.slice(start, end), both Safari and Chrome treat passing undefined
as omitted parameter, while Firefox and IE treat passing undefined as 0. If
it is true that passing undefined should be treated as 0, we do not have a
bug in JSC and V8 bindings layer. However, we do have a bug in JSC and V8
internals.
On Wed, Apr 20, 2011 at 7:28 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 20, 2011, at 6:16 PM, Jian Li wrote:
Hi,
I've just found a problem in our generated code for handling optional
parameters. Suppose we define a method with optional parameter in numeric
type, like the following in IDL:
Foo bar(in [Optional] long long start, in [Optional] long long
end);
And we declare our C++ method as the following. Note that the default
value of the 2nd parameter is not 0.
PassRefPtrFoo bar(long long start = 0, long long end =
std::numeric_limitslong long::max());
If we call the JS method with only 1 parameter, everything works as
expected. However, if we call the JS method with 2 parameters and pass
'undefined' as the 2nd parameter, we trigger the problem.
Is it actually a bug that explicitly passing undefined acts like passing
0, instead of like an omitted parameter? I think it's correct per Web IDL.
What's the specific case where this is a problem?
Regards,
Maciej
By looking into the generated JSC code below, I found out that we are
converting undefined JS value to 0 and pass it to the function. As the
result, the default parameter value in the declaration is not respected.
EncodedJSValue JSC_HOST_CALL jsFooPrototypeFunctionFoo(ExecState* exec)
{
JSValue thisValue = exec-hostThisValue();
if (!thisValue.inherits(JSFoo::s_info))
return throwVMTypeError(exec);
JSFoo* castedThis = static_castJSFoo*(asObject(thisValue));
Foo* imp = static_castFoo*(castedThis-impl());
int argsCount = exec-argumentCount();
if (argsCount = 0) {
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar()));
return JSValue::encode(result);
}
long long start(static_castlong
long(exec-argument(0).toInteger(exec)));
if (exec-hadException())
return JSValue::encode(jsUndefined());
if (argsCount = 1) {
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar(start)));
return JSValue::encode(result);
}
long long end(static_castlong
long(exec-argument(1).toInteger(exec)));
if (exec-hadException())
return JSValue::encode(jsUndefined());
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar(start, end)));
return JSValue::encode(result);
}
One solution is to add the default value support in IDL. For example, we
can change the above definition of bar to something like:
Foo bar(in [Optional, DefaultValue=0] long long start, in
[Optional, DefaultValue=2147483647] long long end);
Or the other way is to add a bool parameter for each optional parameter in
the class method declaration, that is used to indicate if the passing
parameter is defined or not. This would involve the change to both code
generator scripts and the existing implementations.
How do you think? Personally I like the 1st approach since it is simpler.
Thanks,
Jian
___
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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
