Pattern matching has been considered before, and the performance will suck if you consider things like `Point(x, y)`. It's very hard to optimize at runtime, and engines don't have time to optimize that statically.
If you want to consider Clojure as an example of one that does this dynamically, it still works ahead of time. The inheritance chain is known statically, and Clojure uses immutable ADTs primarily, so it can do this very quickly. (Spoiler alert: I've tried proposing this myself. It didn't work. You can find previous talk by searching esdiscuss.com via Google.) On Sat, May 14, 2016, 12:17 G. Kay Lee < [email protected]> wrote: > This is another really far shot - but I'd rather suggest that we should > redefine the role of `case` so that it's no longer just a part of the > `switch` statement but something more generic, as well as introducing a > `match` keyword to enable pattern matching, including the power of matching > by type, so that we can achieve the desired effect in a way illustrated in > the snippets below: > > ``` > // plain old switch-case > > switch (expression) { > case value1: > case value2: > ... > break; > > default: > ... > } > > // switch-case with pattern matching; pattern-match by type in this example > > switch (expression) match { > case _: boolean > ... > break; > > default: > ... > } > > // try-catch with pattern matching > > try { > ... > } catch (error) match { > case _: TypeError > case _: SyntaxError > ... > break; > > default: > ... > } > ``` > > Just some rough idea; inspired by Scala syntax. > > > > On Sat, May 14, 2016 at 1:49 AM, Joseph Groseclose <[email protected]> > wrote: > >> I offered a few syntaxes for this, perhaps the bitwise OR "|" would be >> better. >> >> On Fri, May 13, 2016 at 1:33 PM, Michał Wadas <[email protected]> >> wrote: >> >>> > } catch (await FCL.load(...), await FCL.load(...)) (e) { >>> Then you have to override comma operator ( >>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Comma_Operator >>> ) in one specific context... >>> >>> On Fri, May 13, 2016 at 7:14 PM, Joe Groseclose <[email protected]> >>> wrote: >>> >>>> @JoePea, that is one of the syntaxes I recommend in the proposal. >>>> >>>> @michalwadas The primary goal of this I think is to create a standard >>>> feature, but I do not see why an expression wrapped in parenthesis >>>> ultimately resulting in an error class would not be supported. >>>> >>>> Example: >>>> >>>> ... >>>> >>>> } catch (await FCL.load(...), await FCL.load(...)) (e) { >>>> ... >>>> >>>> Or something similar for all of the other recommended syntaxes, >>>> replacing the declared class instead with an expression (similar to class >>>> extension). >>>> >>>> Sent from my iPhone >>>> >>>> > On May 13, 2016, at 12:54 PM, /#!/JoePea <[email protected]> wrote: >>>> > >>>> > Perhaps a syntax based on modules: >>>> > >>>> > ```js >>>> > try {} >>>> > catch (TypeError as e) {} >>>> > >>>> > // ... >>>> > >>>> > try {} >>>> > catch (MyError as err) {} >>>> > ``` >>>> > >>>> >> On Fri, May 13, 2016 at 9:43 AM, Michał Wadas <[email protected]> >>>> wrote: >>>> >> I can't see why would your syntax be superior to SpiderMonkey >>>> extension >>>> >> except saving few characters. >>>> >> >>>> >> Can your syntax support code like this: >>>> >> >>>> >> async function foo() { >>>> >> try { >>>> >> throw new Error(); >>>> >> } catch(e if isNativeException(e)) { >>>> >> // special handler for DOM exceptions >>>> >> } catch(e if e instanceof (await >>>> >> fancyClassLoader.load('classes/SomeLibrary/UserDefinedError'))) { >>>> >> // load class asynchronously if it wasn't loaded >>>> >> } >>>> >> } >>>> >> >>>> >> ? >>>> >> >>>> >> >>>> >> On Fri, May 13, 2016 at 5:58 PM, Joseph Groseclose < >>>> [email protected]> >>>> >> wrote: >>>> >>> >>>> >>> I've updated the proposal. See: >>>> >>> >>>> https://github.com/benderTheCrime/error-type-specific-catch-proposal#about-spidermonkey-implementation >>>> >>> >>>> >>> On Fri, May 13, 2016 at 11:49 AM, Joseph Groseclose < >>>> [email protected]> >>>> >>> wrote: >>>> >>>> >>>> >>>> Nevertheless, perhaps the non-standard implementation could work >>>> >>>> hand-in-hand with the proposal, where SpiderMonkey could support >>>> both >>>> >>>> solutions in parallel for backward compatibility. I think that the >>>> proposed >>>> >>>> solution is more expressive. >>>> >>>> >>>> >>>> On Fri, May 13, 2016 at 11:26 AM, Claude Pache < >>>> [email protected]> >>>> >>>> wrote: >>>> >>>>> >>>> >>>>> Note that SpiderMonkey has already nonstandard conditional catch >>>> >>>>> clauses: >>>> >>>>> >>>> >>>>> ```js >>>> >>>>> try { >>>> >>>>> // ... >>>> >>>>> } >>>> >>>>> catch (e if e instanceof TypeError) { >>>> >>>>> // .... >>>> >>>>> } >>>> >>>>> ``` >>>> >>>>> >>>> >>>>> —Claude >>>> >>>>> >>>> >>>>> >>>> >>>>> Le 13 mai 2016 à 17:06, Joseph Groseclose <[email protected]> >>>> a écrit >>>> >>>>> : >>>> >>>>> >>>> >>>>> I sent this proposal via >>>> >>>>> >>>> http://www.ecma-international.org/memento/contribute_TC39_Royalty_Free_Task_Group.php# >>>> >>>>> yesterday evening. Sharing it here now: >>>> >>>>> >>>> https://github.com/benderTheCrime/error-type-specific-catch-proposal >>>> >>>>> >>>> >>>>> >>>> >>>>> _______________________________________________ >>>> >>>>> es-discuss mailing list >>>> >>>>> [email protected] >>>> >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> es-discuss mailing list >>>> >>> [email protected] >>>> >>> https://mail.mozilla.org/listinfo/es-discuss >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> es-discuss mailing list >>>> >> [email protected] >>>> >> https://mail.mozilla.org/listinfo/es-discuss >>>> >> >>>> >>> >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
