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
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 expressi
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,
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 appropriately.
> 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 *anywhere*.
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 enjoyi
> 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 somet
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 y
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 of
Sometimes, (particularly in React codebases) you have to write many lines
like:
```js
export { default as FooBar } from './FooBar';
```
It could be automated of course
It could also be tuned into
```js
export * from './FooBar';
```
only if FooBar is also a named export in that file, but usually fi
10 matches
Mail list logo
