Russell Leggett wrote:
Options type objects:
let {url,callback,?errback} = options;
This lets you very clearly decompose an object and declaratively show
which values are optional and which ones are not. If all of them are
optional, the ? would just go to the left of the brace, but really
this should be the minority case for most situations.
Dave and I had talked about prefix-? as applying only to property names,
since that covers all but the top level for object patterns:
{required, ?optional_shallow}
{required, ?optional_deep: {foo, bar, ?baz}}
but of course it leaves out the top level.
If we make prefix-? apply to the "value" side of the ":" (which in
object patterns is optional, but if present names the binding not the
property), then we have
{required, optional_shallow: ?renamed_optional_shallow}
{required, optional_deep: ?{foo, bar, ?baz}}
and the object shorthand would still be wanted:
{required, ?optional_shallow}
This is a strictly larger grammar, though. If we can keep prefix-? in
the property name side, then all we lose is the top level.
Array patterns don't have explicit "0", "1", "2", etc., property names,
though so either prefix-? doesn't work, or you have to use an object
pattern (which works on array values), or else prefix-? goes before the
binding name (the "value" side) as above.
A disparate list of possible types of matches. This is common in
"overloaded" functions where the number and type of arguments can be
wildly different. This is probably the strongest case against
refutable matching, because it is so likely to result in mismatches
which should have logic performed on them instead of having an error
thrown.
Right, this minority case could be left out. The array pattern situation
is stronger motivation for prefix-? applying to bindings not property names.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
