Thanks for the clarification - this helps.
I think however that the constructors of the Globalization API handle this
correctly in most cases. The specs for the cases where the options object is
not provided (sections /(8|9|10).2.(2|3)/), say the constructors behave as if
they had received a minimal default, but that means they then also use all the
other defaults. Effectively, they do:
// handle missing options
if (!ops) {
ops = { foo: defFoo };
}
// normal processing
if (typeof ops.foo === "undefined") {
foo = defFoo;
}
if (typeof ops.bar === "undefined") {
bar = defBar;
}
if (typeof ops.baz === "undefined") {
baz = defBaz;
}
That's a bit redundant, but generally produces the right results.
Maybe breaking the constructor specifications into three subsections is just
confusing, and I should merge them into one?
There is a real problem, however, in the handling of date format components
(10.2.1, and also the strawman for Date.prototype.toLocale(|Date|Time)String):
The default for these components individually is undefined, meaning that the
formatted string should only have the components that the caller requested.
However, if the caller didn't request any components, then a default set should
be filled in. With the current spec, the default set is only filled in if no
options object is provided at all. If the caller, say, wants to request 24-hour
time, it currently also has to specify the components. That's something I need
to fix.
The Globalization constructors don't modify the caller-provided options, by the
way - I think that's a problem in your code.
Thanks,
Norbert
On Nov 19, 2011, at 22:40 , David Herman wrote:
> On Nov 19, 2011, at 5:50 PM, Brendan Eich wrote:
>
>> On Nov 19, 2011, at 2:20 PM, Rick Waldron wrote:
>>
>>> Q. We don't use option parameter like that in JS (see previous point for
>>> actual example)
>>>
>>> Using an object-as-option parameter is a very common API design pattern in
>>> real-world JavaScript today - why anyone would say otherwise is
>>> confounding.
>>
>> Right. For example, ES5's property descriptor and property descriptor map
>> parameters.
>
> It was me. I didn't say JS doesn't use options objects. I said the G11n
> library was using them wrong. They were doing:
>
> if (!ops) {
> ops = { foo: defFoo, bar: defBar, baz: defBaz };
> }
>
> instead of e.g.:
>
> if (!ops)
> ops = {};
> if (typeof ops.foo === "undefined")
> ops.foo = defFoo;
> if (typeof ops.bar === "undefined")
> ops.bar = defBar;
> if (typeof ops.baz === "undefined")
> ops.baz = defBaz;
>
> IOW, it shouldn't be all or nothing, but rather each property of the options
> object is separately optional.
>
> Dave
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
