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
