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 <
balancetraveller+es-disc...@gmail.com> 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 <jgrosec...@gmail.com>
> 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 <michalwa...@gmail.com>
>> 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 <jgrosec...@gmail.com>
>>> 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 <j...@trusktr.io> 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 <michalwa...@gmail.com>
>>>> 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 <
>>>> jgrosec...@gmail.com>
>>>> >> 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 <
>>>> jgrosec...@gmail.com>
>>>> >>> 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 <
>>>> claude.pa...@gmail.com>
>>>> >>>> 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 <jgrosec...@gmail.com>
>>>> 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
>>>> >>>>> es-discuss@mozilla.org
>>>> >>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>> >>>
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> es-discuss mailing list
>>>> >>> es-discuss@mozilla.org
>>>> >>> https://mail.mozilla.org/listinfo/es-discuss
>>>> >>
>>>> >>
>>>> >> _______________________________________________
>>>> >> es-discuss mailing list
>>>> >> es-discuss@mozilla.org
>>>> >> https://mail.mozilla.org/listinfo/es-discuss
>>>> >>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
