If it only does `===`, then it's not much better than switch.
It would be interesting to see a pattern matching proposal that was
extensible/customizable, perhaps via a well-known Symbol method.
On Fri, Jun 30, 2017 at 9:06 AM, Andreas Rossberg
wrote:
> On 30 June 2017 at
On 30 June 2017 at 15:55, Henrik Sommerland
wrote:
> Why is there no support for pattern matching in JavaScript?
> I would guess that it has been proposed before, and if so why hasn't it
> been included?
>
> I have been thinking about it and I think it would
-1. will pattern matching code written by the vast number of beginner
javascript programmers be readable/maintainable? i personally think not.
yet another duplicative feature (that can probably be done more
maintainably by switch statements or the all-powerful
String.prototype.replace) to further
I would pick === without a doubt.
One may consider providing some form of optional syntax to do this like {b
~: 5} but I think that the safe way should be the default way.
If the decision is made to support both strict comparisons and the silly
ones (I'm a bit biased :p ) there could beseveral
A question though, would this be equivalent to == or === matching for specific values? Namely does {b: 5} match with a passed in object that has {b:'5'}?Sebastian
Yes :)
This is roughly what I had in mind:
match obj with
{a, b : 5} -> return a + b
{a, c : {d, e : true}} -> return a + d
'rof' -> return 'lol'
Where the first clause matches if obj has the property a and the property b
that has the value 5.
The second clause works the same but
Are you thinking kind of like Rust's match statement? I think that something like that would be quite a good addition.Sebastian
Why is there no support for pattern matching in JavaScript?
I would guess that it has been proposed before, and if so why hasn't it
been included?
I have been thinking about it and I think it would integrate nicely into
JavaScript.
If it hasn't been proposed already I would propose it, and I
I just removed performance from goals of the proposal, given how it seems to
depend about how min and max are called.
Thanks for feedbacks.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Fri, Jun 30, 2017 at 7:53 AM, Boris Zbarsky wrote:
> On 6/29/17 1:49 AM, T.J. Crowder wrote:
>
>> I was going to make that very point, backed by a jsPerf, but the jsPerf
>> doesn't back it up: https://jsperf.com/two-calls-vs-one-returning-array
>> It says the minmax is
On 6/29/17 1:49 AM, T.J. Crowder wrote:
I was going to make that very point, backed by a jsPerf, but the jsPerf
doesn't back it up: https://jsperf.com/two-calls-vs-one-returning-array
It says the minmax is faster on a 10-entry array (it reports the
separate calls as 46-48% slower on V8 and
11 matches
Mail list logo