Re: Proposal: switch expressions

By "simulating", I meant doing something that was functionally equivalent. If you wanted a direct equivalent, just replace all instances of `{keyN: true, print: function () { ... }}` with `new class { constructor() { this.keyN = true } print() { ... } }` in the benchmarks, and you've got something

Re: Proposal: switch expressions

IIUC the "object dispatch integer"/"object dispatch string" benchmarks are the things you were referring to. Those simulate what the engine would see with virtual dispatch and completely different type maps, just without the source overhead of creating an entire class just for a little benchmark.

Re: Proposal: switch expressions

> It would be unthinkable for it to use pattern matching or explicit code > branching instead of method inheritance for type disambiguation during render But it frequently does internally. For example: - Calculating object projections:

Re: Proposal: switch expressions

The entire renderers, cameras, meshes etc. hierarchy uses method inheritance and many of those methods are called during scene rendering (which is performance sensitive as it happens per frame). It would be unthinkable for it to use pattern matching or explicit code branching instead of method

Re: Proposal: switch expressions

I'm looking at Three.js's code base, and I'm not seeing any method overriding or abstract methods used except at the API level for cloning and copying. Instead, you update properties on the supertype. As far as I can tell, the entirety of Three.js could almost be mechanically refactored in terms

Re: Proposal: switch expressions

I'm not sure that pattern matching handles deep levels of inheritance more elegantly than inheritance itself. If there is a conceptual type hierarchy, then the ability to call "super", combine it with specialized functionality, etc. is a lot more manageable using localized, separated logic where

Re: Proposal: switch expressions

> While the pattern-matching proposal does cover a much richer matching, it > still doesn't target the issue of being a statement vs an expression. Part > of my initial motivation is that the evaluation of the switch returns a > value, which pattern-matching doesn't resolve. That's still

Re: Proposal: switch expressions

Isiah, While the pattern-matching proposal does cover a much richer matching, it still doesn't target the issue of being a statement vs an expression.  Part of my initial motivation is that the evaluation of the switch returns a value, which pattern-matching doesn't resolve. Very much

Re: Proposal: switch expressions

> Using a "switch" here forces you to group classes of objects together and > then you don't get the 2nd, 3rd, 4th etc. levels of specialization that you > might later want. Sometimes, this is actually *desired*, and most cases where I could've used this, inheritance was not involved

Re: Proposal: switch expressions

Hi David! Your last example would, I think, be better served by classes and inheritance, than switch. Dogs are house animals which are animals Cheetas are wild cats which are animals Each could have overridden methods, entirely optionally, where the method gets called and resolves

Re: Proposal: switch expressions

Naveen, Thanks for your observation.  The example that I gave might have been too simplistic, here's a more complete example: ``` switch (animal) { case Animal.DOG, Animal.CAT => { // larger block expression // which spans multiple lines return "dry food"; } case Animal.TIGER, Animal.LION,

Re: Proposal: switch expressions

Kai, Thanks for the feedback and the real world example. Most of my examples have been focused on simple cases.  The full example is something that would support the following style: ```     const food = switch (animal) {   case Animal.DOG, Animal.CAT => {     // larger block

Re: Proposal: switch expressions

Isn't the best existing pattern an object literal? const cases = { foo: ()=>1, bar: ()=>3, baz: ()=>6 } , x = cases[v] ? cases[v]() : 99 ; What does any proposal have that is better than this? With

Re: Proposal: switch expressions

> This is unmaintainable -- > > const x = v === 'foo' ? 1 : v === 'bar' ? 3 : v === 'baz' ? 6 : 99; > i feel proposed switch-expressions are no more readable/maintainable than ternary-operators, if you follow jslint's style-guide. i'll like to see more convincing evidence/use-case that

Re: Proposal: switch expressions

Just for folks who might be interested, added a babel-plugin to see what was involved in making this possible. Pull request available here -- https://github.com/babel/babel/pull/9604 I'm sure I'm missing a bunch of details, but would be interested in some help in making this a bit more real.

Re: Proposal: switch expressions

You're not alone in wanting pattern matching to be expression-based: https://github.com/tc39/proposal-pattern-matching/issues/116 - Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com - Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com On Tue, Feb 26, 2019 at 1:34

Re: Proposal: switch expressions

Jordan, Thanks for taking time to read and provide thoughts. I just back and re-read the pattern matching proposal and it still fails on the basic requirement of being an Expression not a Statement.  The problem that I see and want to address is the need to have something that removes the

Re: Proposal: switch expressions

Pattern Matching is still at stage 1; so there's not really any permanent decisions that have been made - the repo theoretically should contain rationales for decisions up to this point. I can speak for myself (as "not a champion" of that proposal, just a fan) that any similarity to the reviled

Re: Proposal: switch expressions

Jordan, One question that I have lingering from pattern matching is why is the syntax so different? IMHO it is still a switch statement with a variation of the match on the case rather than a whole new construct. Is there somewhere I can find a bit of discussion about the history of the

Re: Proposal: switch expressions

Additionally, https://github.com/tc39/proposal-pattern-matching - switch statements are something I hope we'll soon be able to relegate to the dustbin of history. On Mon, Feb 25, 2019 at 6:01 AM David Koblas wrote: > I quite aware that it’s covered in do expressions. Personally I find do >

Re: Proposal: switch expressions

I quite aware that it’s covered in do expressions. Personally I find do expressions non-JavaScript in style and it’s also not necessarily going to make it into the language. Hence why I wanted to put out there the idea of switch expressions. --David > On Feb 25, 2019, at 5:28 AM, N. Oxer

Re: Proposal: switch expressions

Hi, This would be covered by do expressions . You could just do: ```js const category = do { switch (...) { ... }; }; ``` On Sun, Feb 24, 2019 at 10:42 AM David Koblas wrote: > After looking at a bunch of code in our system noted that

Proposal: switch expressions

After looking at a bunch of code in our system noted that there are many cases where our code base has a pattern similar to this:     let category = data.category;     if (category === undefined) {   // Even if Tax is not enabled, we have defaults for incomeCode   switch