fail-fast object destructuring

Russell Leggett russell.leggett at gmail.com
Mon Jul 9 09:19:54 PDT 2012


On Fri, Jul 6, 2012 at 1:37 PM, Brendan Eich <brendan at mozilla.org> 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 mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120709/3b2846dc/attachment.html>


More information about the es-discuss mailing list