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

[Jian Li]

On Fri, Apr 22, 2011 at 12:21 PM, Kenneth Russell <kbr at 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 <jianli at 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 <oliver at 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 <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
> >>
> >
> >
> > _______________________________________________
> > 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/370aea1c/attachment.html>