[webkit-dev] Optional parameter in IDL and undefined JS value

[Oliver Hunt]

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 <mjs at 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 <mjs at 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110422/afa1f6cd/attachment.html>