What about a more generic operator that would be able to silently absorb
any error?
let greedy = obj.hints?.greedy;
would become:
let greedy = silent obj.hints.greedy;
The semantic would be exactly the same.
The syntax is up to debate. Specifically, it would be nice to be able to
silence a part of an expression.
What about a 'try' without a catch?
let greedy = try obj.hints.greedy
let greedy = try{ obj.hints.greedy } || 22;
This is currently forbidden (I think for 2 reasons, one being that a try
must be followed by a catch or finally and the other that try/catch
cannot be used as expressions)
This idea is partly inspired by typeof which silences ReferenceErrors,
which I see as a feature YMMV.
It is also intended to make programs potentially more robust more
easily. For instance, JSON.stringify can throw errors in the rare case
of cyclic references. But very few people know that. To make a robust
program using JSON.stringify, one would just need to turn:
let s = JSON.stringify(o)
into
let s = try{ JSON.stringify(o) } || DEFAULT_VALUE;
instead of the current:
let s;
try{
s = JSON.stringify(o)
}
catch(e){
// I don't care about the error anyway
s = DEFAULT_VALUE;
}
David
Le 18/06/2012 07:11, Brendan Eich a écrit :
Sorry, meant to start a new thread for:
http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator
As the Syntax section hints, we can't also adopt CoffeeScript's ?(
variant, which enables foo.bar?(args, go, here).baz and the like. The
C syntax heritage prevails.
/be
Brendan Eich wrote:
David Herman wrote:
On Jun 15, 2012, at 5:57 PM, satyr wrote:
On Sat, Jun 16, 2012 at 4:33 AM, David Herman <dher...@mozilla.com
<mailto:dher...@mozilla.com>> wrote:
As for null, I can see how there's confusion about whether to use
null vs undefined, and so I can see why CoffeeScript would just
try to blur the distinction between them.
Not just for blurring. Rejecting `null` is essential for
CoffeeScript's "existence" due to `?.`, the soak/safe access operator.
I think you could make a case for ?. defaulting for both but ??
defaulting only undefined. The case goes something like this:
- The purpose of ?? is to provide a default value when no value was
provided. The way to say "no value" in JavaScript is undefined.
- The purpose of ?. is to fail soft when doing a property lookup.
Both null and undefined throw when doing a property lookup.
Agreed. This is one choice, it's plausible because of the distinction
between defaulting (which requires intentional passing of a "please
default" sentinel value, or not passing a trailing actual argument)
and soaking up null-or-undefined.
Yes, we could make ?? and ??= do the same for null as for undefined.
I'm not sure that's the right choice, but it's a choice. For
foo.bar?.baz, though, the clearer choice is to avoid throwing, which
means evaluating to undefined if foo.bar is missing (evaluates to
undefined) *or* has a value not coercible to object type (null or
undefined). See
http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
