fail-fast object destructuring

Claus Reinke claus.reinke at talk21.com
Tue Jun 26 09:25:27 PDT 2012


> 3) Again we have a internal consistency issue:
> 
>   let myFoo = {a:0,b:1}.foo;
> vs
>   let {foo: myFoo} = {a:0,b:1};
> 
> why should one work and the other fail?  The general 
> rule of JS is that accessing a missing property returns undefined. 

Ultimately, I'd like to have both:

- irrefutable matching:
    here, the two phrases above are equivalent, as in the
    destructuring proposal

- refutable matching:
    here, the latter phrase would fail, ideally in a way that
    can be recovered from efficiently, to guard against interface
    mismatches and to implement pattern matching with fall 
    through, as in the pattern_matching strawman "switch/match"

One is a syntactic convenience for selection only, the other
for selection plus structural tests (actually: behavioral interface
tests, see below). Both have their uses.

This suggests having pattern syntax modifiers for indicating 
refutable or irrefutable matching, and deciding which of the 
two is likely to be more common (and thus to be the default 
for patterns without modifiers).

That would also make pattern semantics more uniform, instead
of selecting refutable or irrefutable semantics based on context
(switch/match or other).

There is a separate question of structural vs behavioral
matching. Functional programming fans like me will be 
tempted to think of the former, but in current JS, only 
the latter seems to make sense:

- values can be coerced to objects
- objects can inherit properties via __proto__
- getters are virtual properties
- proxies can front for objects

So the question is less "how the target is laid out in memory" 
and more "how the target behaves". I find it useful to remind
myself of this difference between JS and other functional languages.

On the other hand, there are strawmen for non-object data 
structures, such as records. I don't know whether those will 

- tip the balance, so that both structural and behavioral matching
    will be needed, 
- make the question moot, because we will use records when
    we mean structural matching and objects when we mean
    behavioral matching

Since ES cannot easily deprecate functionality, let alone syntax,
it would be good to look ahead: how do destructuring and
matching relate? what will it mean to destructure records instead
of objects? How do functional programming patterns based on
structural matching translate to the multi-paradigm language JS,
with its behavioral matching?

Claus
    
 


More information about the es-discuss mailing list