fail-fast object destructuring

Claus Reinke claus.reinke at talk21.com
Thu Jul 5 13:41:01 PDT 2012


>>     We could try to have our cake and eat it, by extending the pattern
>>     language with prefix-! or prefix-?. Which prefix depends on the
>>     choice of default behavior, based on ranking of the two
>>     equivalences. Whatever that ranking, does this make sense so far?
>>
>> Sure, I'm all for that. As long as they -- and the rest of the pattern 
>> language -- have the same meaning in all contexts.

> Comments from es-discuss peanut gallery welcome.

Some peanuts:

This consistency of meaning, with the ability to choose refutable or
irrefutable patterns wherever patterns are permitted, is important,
because fewer special cases lead to an easier-to-understand language.

Current variables in assignments and formal arguments are special
cases of more general patterns, and they do not have prefixes.
Fortunately, variables behave the same in refutable and irrefutable
matching.

When variable patterns get extended with as-patterns, those will
make sense in both refutable and irrefutable forms, for different
uses.

When patterns get extended with type guards in future, those
seem to require refutable matching. Irrefutable type guards
might allow for running typed code in an unsafe manner, but
one would have to think about what that means (type exceptions
on first access?).

>From experience with Haskell's patterns, while it makes sense to
have irrefutable patterns nested inside refutable ones, the other
direction is less helpful. Haskell's patterns also impact on strictness
(whether and how far the argument is evaluated), which is not an
issue in JS. 

However, if the general issue (that nesting prefers one default 
over the other) carries over to JS, then making irrefutable 
patterns the default will lead to lots of prefixes in patterns 
(marking the whole path through the pattern).
 
> Allen rallied me to the prefix-! route by objecting that prefix-? would 
> not be available outside of patterns, which simply highlights how JS 
> already imputes undefined for missing property.

Could you expand on this? Refutable vs irrefutable only applies 
to patterns so far, though one could imagine property selectors with
early failure to complement the current succeed-with-undefined.
 
Claus
 


More information about the es-discuss mailing list