fail-fast object destructuring

Russell Leggett russell.leggett at
Mon Jul 9 09:55:15 PDT 2012


On Mon, Jul 9, 2012 at 12:54 PM, Russell Leggett
<russell.leggett at>wrote:

> ::faceplam::
> On Mon, Jul 9, 2012 at 12:36 PM, Andreas Rossberg <rossberg at>wrote:
>> I agree with almost everything you said. But just to clarify, I think you
>> actually meant "refutable" everywhere you said "irrefutable".
>> /Andreas
>> On 9 July 2012 18:19, Russell Leggett <russell.leggett at> wrote:
>>> On Fri, Jul 6, 2012 at 1:37 PM, Brendan Eich <brendan at>wrote:
>>>> Andreas Rossberg wrote:
>>>>>     We should talk more at this month's TC39 meeting, but I see a
>>>>>     sharp divide ahead:
>>>>>     1. Choose (A), possibly with modification, either rejecting useful
>>>>>     pattern matching decisively, or else making its pattern language
>>>>>     differ by making prefix-! implicit. But you rejected splitting
>>>>>     pattern meaning across destructuring and future pattern-matching,
>>>>>     in the last sentence cited above.
>>>>>     XOR
>>>>>     2. Choose (B) because future-proofing for pattern matching wants
>>>>>     prefix-?, and impose a compatibility break from what we and others
>>>>>     implemented, and what most JS users might expect based on JS's
>>>>>     carefree imputing of undefined.
>>>>> Agreed.
>>>>>     Comments from es-discuss peanut gallery welcome.
>>>>>     I could go for 1/A, except for two facts. First, I believe there
>>>>>     is a non-trivial body of Firefox JS that depends on imputing
>>>>>     undefined. Second, and what is more important: we haven't
>>>>>     usability-tested 2/B at all.
>>>>> Did you mean "could go for 2/B" there?
>>>> Evidently!
>>>> I rearranged and renumbered but missed this one. Clearly I meant 2/B.
>>>> I'm a bit unhappy about making such a change so long after implementing 1/A
>>>> (without prefix-!). But never mind me -- what do others think?
>>> I would love to see 2/B. A lot of that is likely because I would love to
>>> see pattern matching, though, I'll admit. I think that the ? on refutable
>>> portions of the pattern would work well with the new default and
>>> existential operators, while I think ! will not have a good analog. If I
>>> were to throw out another reason based on destructuring assignment alone,
>>> and not pattern matching later, I would say that if parts of the
>>> destructuring are likely to fail, it would be better to know upfront. If
>>> there are optional fields, ? clearly expresses that. If there are wildly
>>> unknown structures, destructured assignment is probably not the best
>>> approach, or at least there should be some structural testing upfront
>>> (pattern matching would of course be ideal).
>>> As for usability testing, while it obviously is not done irrefutably in
>>> spidermonkey now, I think we can at least look to other languages. Looking
>>> over several languages, all of the ones I have seen are irrefutable. Some
>>> are strongly typed languages, but not all. Python does not have complete
>>> patterns, it can basically just destructure list, but even it requires that
>>> the number of elements be correct. Erlang, OCaml, and F# all allow full
>>> pattern assignments, and they will all throw errors if not correctly
>>> matched. Obviously, it is a little different than what it would be in ES,
>>> they have full on patterns not just destructuring, but it would clearly be
>>> all the more consistent when patterns *hopefully* get added. I know that JS
>>> users have come to expect a certain amount of carefree imputing, but
>>> destructuring is new (outside of FF), and I think it is certainly an area
>>> which has options. I haven't exactly done a formal survey of languages, but
>>> from what I've seen JS would be the first to be so lenient. Allowing ? in
>>> portions of a pattern, I actually think would be the perfect compromise.
>>> People who write very loose code will either have to put ?s on their
>>> patterns or keep working the same way they have been, but if there isn't a
>>> reasonable amount of checking by default, I think we're going to be seeing
>>> some more WATs in presentations. JS gets picked on for how much coercion
>>> and silent errors it will chug along with. Best practices of always using
>>> === and avoiding 'with' are just a couple of examples.
>>> Finally, I would like to take the approach of looking at the best way to
>>> handle the different use cases.
>>>    1. Really simple destructuring with expected results:
>>>        let {x,y} = getPoint();
>>>    In my opinion, this should throw if x or y are not available. It is
>>>    unlikely that the coder is checking properties here, they are just going to
>>>    call other functions passing through x or y. It would probably be better to
>>>    get the error as soon as possible. Much easier to debug that way. In many
>>>    cases, I think these types of destructuring assignments will lead to
>>>    effortless checking that would previously have been missed because of the
>>>    extra effort to add those checks in as if statements.
>>>    2. 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.
>>>    3. 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 irrefutable
>>>    matching, because it is so likely to result in mismatches which should have
>>>    logic performed on them instead of having an error thrown. However, it is
>>>    also the strongest case for pattern matching. There is nothing wrong with
>>>    wanting to accept differently shaped things, but right now there is not
>>>    really a great facility for acting on them. Pattern matching would be
>>>    ideal. I think it would be such a powerful addition to the language as it
>>>    is used right now, that it honestly pains me that we would cut out the
>>>    possibility. I would love to see patterns now, but I can understand
>>>    waiting. Making a decision which would close it off though would be
>>>    extremely disappointing.
>>> I know that full blown patterns are out of scope (though I'm hoping
>>> maybe this discussion might change that), but even if we can't have it now,
>>> I think irrefutable destructuring would really make people see the
>>> potential. Even if no facility was provided for it, a hypothetical match
>>> function could be created which would take function and execute them in
>>> sequence in a try catch until one did not fail. I think we can do better
>>> than that and should probably try if we go with irrefutable destructuring,
>>> but just knowing it would be possible for the community to take and run
>>> with is nice.
>>> - Russ
>>>> /be
>>>> ______________________________**_________________
>>>> es-discuss mailing list
>>>> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list