Globalization API discussion

Brendan Eich brendan at mozilla.com
Mon Nov 21 10:25:06 PST 2011


On Nov 21, 2011, at 9:52 AM, Allen Wirfs-Brock wrote:

> On Nov 20, 2011, at 8:30 PM, Brendan Eich wrote:
> 
>> On Nov 20, 2011, at 1:18 PM, David Herman wrote:
>> 
>>>> I would not add more implicit magic to JS. E4X had junk like this in it, which only ever concealed bugs.
>>> 
>>> I'm of two minds about this. In the abstract, I agree with Brendan; fail-soft conceals bugs. But in reality, our destructuring logic is incredible fail-soft. Hardly anything in destructuring is treated as an error. And the syntax really *wants* to match the common pattern. So I'm torn.
>> 
>> 1. Failing to write that means a destructuring parameter with default values within the pattern cannot be observed via arguments[i] as undefined (or null?). If missing, the undefined will be replaced by a fresh object. This isn't consistent with any other combination of destructuring parameters and parameter default values.
>> 
>> 2. If a function wants to throw an error for a missing options parameter, it has no way of telling other than arguments.length checking.
> 
> function f({a,b} = (optionsMissing=true,{})) {
>    var optionsMissing;
>    if (optionsMissing) throw "missing options parameter";
>    ...
> 
> or using Dave's do operator:
> 
> function f({a,b} = do{ throw "missing options parameter",({})}) {

Ok, that's plausible for such a hard case. Let's get to 3, and past it.


>> 3. It's not hard to write " = {}".
> 
> I agree.  I'm a little uncomfortable with exceptions originating from formal parameter initialization, but as soon as we allowed for default value expressions that became a possibility.  Overall, I suspect that implicitly providing a "={}" is just going to mask logic errors.

Also, how deep do you go:

function deep({{{hi = "there"}}}) {...}

deep() // this creates three objects?

The object creation could be optimized away, maybe, but the smell is getting worse. EIBTI.

/be


More information about the es-discuss mailing list