Globalization API discussion

Norbert Lindenberg ecmascript at norbertlindenberg.com
Sun Nov 20 15:00:14 PST 2011


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
> 



More information about the es-discuss mailing list