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
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
