destructuring: as patterns?

Allen Wirfs-Brock allen at wirfs-brock.com
Thu Apr 19 17:15:22 PDT 2012


On Apr 19, 2012, at 4:16 PM, David Herman wrote:

> On Apr 19, 2012, at 2:18 PM, Allen Wirfs-Brock wrote:
> 
>> //initialize some variable with default objects
>> let {
>>    unidentifedAdult: mom,
>>    unidetifiedAdult: dad, 
>>    unidentiedChild: brother,
>>    unidentifiedChild: sister
>>    } = peopleConstants;
>> 
>> why is this less desirable than:
>> 
>> //initialize some variable with default objects
>> let mon = peopleConstants.unidentifiedAdult,
>>     dad = peopleConstants.unidentifiedAdult,
>>     brother = peopleConstants.unidentifiedChild,
>>     sister = peopleConstants.unidentifiedChild;
> 
> Well, it's rare that you *need* to re-evaluate the dot-pattern. It saves typing, repetition (DRY!), side-effects, and running time to evaluate each selector only once:
> 
>    let mom = peopleConstants.unidentifiedAdult,
>        dad = mom,
>        brother = peopleConstants.unidentifiedChild,
>        sister = brother;
> 
DRY isn't the only principle in play in situations like this.  

   let mom = peopleConstants.unidentifiedAdult,
       dad = mom,

Expresses a coupling between dad and mom that may not actually be inherent in the actual problem domain. If we change the initialization of mom and we will also change the initialization of dad. If I want to couple them in that manner, I would probably say:
    let dad = mom = peopleConstants.unidentifiedAdult;

Also chains of indirection may programs harder to understand when reading them. 

The example intentionally used an object pattern that looked like a namespace. If you have to worry about side-effects of namespace element accesses you're already screwed. I wouldn't go out of my way to minimize reevaluation of access of namespace elements unless you have identified it is being in a hot loop. We all know the premature optimization mantra. 

It really doesn't matter what your or my preferred style might me.  There are many reasonable coding style and engineering trade-offs.  The point was that there is nothing inherently "bad" about the first alternative above and that somebody might choose to adopt that idiom.  JS is a vary tolerant language.  Given everything else we allow, why should be forbid this?

> And you should be able to do that just fine with nested as-patterns:

Clearly there are other ways, but why forbid the one above?

> 
>    let { unidentifiedAdult: mom as dad, unidentifiedChild: sister as brother }
> 
> or
> 
>    let { undentifiedAdult as mom as dad, unidentifiedChild as sister as brother }
> 

I actually  I found
      propertyName :  bindingIdentifier as bindingPattern

(do I have the subparts right?) somewhat confusing at first and I think other might also.  What is the difference between : and |as|?  Why are different things allowed after each?  Only one |as|?  I actually think your second alternative is clearer but why not:

 let {unidentifiedAdult : mom : dad : auntie, unidentifiedChild : sister : brother} = peopleComstants.

If you think about destructuring simply as an alternative initialization syntax that seems to make more sense.  Essentially : and = are duals that operate in opposite directions:

       let {unidentifiedAdult : mom : dad : auntie} = peopleComstants;  //right to left initialization
vs
       let mom = dad = auntie = peopleComstants. unidentifiedAdult;  //left to right initialization

Allen








> Dave
> 
> 



More information about the es-discuss mailing list