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 need to chain trinary
expressions together to have an Expression.
This is unmaintainable --
const x = v === 'foo' ? 1 : v === 'bar' ? 3 : v === 'baz' ?
6 : 99;
This is maintainable, but is less than ideal:
let x;
switch (v) {
case "foo":
x = 1;
break;
case "bar":
x = 3;
break;
case "baz":
x = 6;
break;
default:
x = 99;
break;
}
Pattern matching does shorten the code, but you have a weird
default case and also still end up with a loose variable and
since pattern matching is a statement you still have a
initially undefined variable.
let x;
case (v) {
when "foo" -> x = 1;
when "bar" -> x = 3;
when "baz" -> x = 6;
when v -> x = 99;
}
Let's try do expressions, I'll leave people's thoughts to
themselves.
const x = do {
if (v === "foo") { 1; }
else if (v === "bar") { 3; }
else if (v === "baz") { 6; }
else { 99; }
}
Or as another do expression variant:
const x = do {
switch (v) {
case "foo": 1; break;
case "bar": 3; break;
case "baz": 6; break;
default: 99; break;
}
}
And as I'm thinking about switch expressions:
const x = switch (v) {
case "foo" => 1;
case "bar" => 3;
case "baz" => 6;
default => 99;
}
What I really like is that it preserves all of the normal
JavaScript syntax with the small change that a switch is
allowed in an expression provided that all of the cases
evaluate to expressions hence the use of the '=>' as an
indicator. Fundamentally this is a very basic concept where
you have a state machine and need it switch based on the
current state and evaluate to the new state.
const nextState = switch (currentState) {
case ... =>
}
On 2/25/19 4:00 PM, Jordan Harband wrote:
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 and terrible
`switch` is something I'll be pushing back against - I want a
replacement that lacks the footguns and pitfalls of `switch`,
and that is easily teachable and googleable as a different,
distinct thing.
On Mon, Feb 25, 2019 at 12:42 PM David Koblas <da...@koblas.com
<mailto:da...@koblas.com>> wrote:
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 syntax decisions?
--David
On Feb 25, 2019, at 12:33 PM, Jordan Harband <ljh...@gmail.com
<mailto:ljh...@gmail.com>> wrote:
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 <da...@koblas.com
<mailto:da...@koblas.com>> wrote:
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 <bluesh...@gmail.com
<mailto:bluesh...@gmail.com>> wrote:
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
<da...@koblas.com <mailto:da...@koblas.com>> wrote:
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 (session.merchant.settings.tax.incomeCode) {
case TaxIncomeCode.RENTS_14:
category = PaymentCategory.RENT;
break;
case TaxIncomeCode.INDEPENDENT_PERSONAL_SERVICE_17:
category = PaymentCategory.SERVICES;
break;
case TaxIncomeCode.INDEPENDENT_PERSONAL_SERVICE_17:
category = PaymentCategory.SERVICES;
break;
}
}
I also bumped into a block of go code that also implemented
similar
patterns, which really demonstrated to me that there while
you could go
crazy with triary nesting there should be a better way.
Looked at the
pattern matching proposal and while could possibly help
looked like it
was overkill for the typical use case that I'm seeing. The
most relevant
example I noted was switch expressions from Java. When
applied to this
problem really create a simple result:
const category = data.category || switch
(setting.incomeCode) {
case TaxIncomeCode.RENTS_14 => PaymentCategory.RENT;
case TaxIncomeCode.ROYALTIES_COPYRIGHTS_12 =>
PaymentCategory.ROYALTIES;
case TaxIncomeCode.INDEPENDENT_PERSONAL_SERVICE_17 =>
PaymentCategory.SERVICES;
default => PaymentCategory.OTHER;
}
Note; the instead of using the '->' as Java, continue to use
=> and with
the understanding that the right hand side is fundamentally
function.
So similar things to this are natural, note this proposal
should remove
"fall through" breaks and allow for multiple cases as such.
const quarter = switch (foo) {
case "Jan", "Feb", "Mar" => "Q1";
case "Apr", "May", "Jun" => "Q2";
case "Jul", "Aug", "Sep" => "Q3";
case "Oct", "Nov", "Dec" => { return "Q4" };
default => { throw new Error("Invalid Month") };
}
Also compared this to the do expression proposal, it also
provides a
substantial simplification, but in a way that is more
consistent with
the existing language. In one of their examples they
provide an example
of the Redux reducer
https://redux.js.org/basics/reducers#splitting-reducers --
this would be
a switch expression implementation.
function todoApp(state = initialState, action) => switch
(action.type) {
case SET_VISIBILITY_FILTER => { ...state,
visibilityFilter:
action.filter };
case ADD_TODO => {
...state, todos: [
...state.todos,
{
text: action.text,
completed: false
}
]
};
case TOGGLE_TODO => {
...state,
todos: state.todos.map((todo, index) => (index ===
action.index) ? { ...todo, completed: !todo.completed } : todo)
};
default => state;
}
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
On 2/25/19 3:42 PM, David Koblas wrote:
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 syntax decisions?
--David
On Feb 25, 2019, at 12:33 PM, Jordan Harband <ljh...@gmail.com
<mailto:ljh...@gmail.com>> wrote:
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 <da...@koblas.com
<mailto:da...@koblas.com>> wrote:
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 <bluesh...@gmail.com
<mailto:bluesh...@gmail.com>> wrote:
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
<da...@koblas.com <mailto:da...@koblas.com>> wrote:
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 (session.merchant.settings.tax.incomeCode) {
case TaxIncomeCode.RENTS_14:
category = PaymentCategory.RENT;
break;
case TaxIncomeCode.INDEPENDENT_PERSONAL_SERVICE_17:
category = PaymentCategory.SERVICES;
break;
case TaxIncomeCode.INDEPENDENT_PERSONAL_SERVICE_17:
category = PaymentCategory.SERVICES;
break;
}
}
I also bumped into a block of go code that also implemented
similar
patterns, which really demonstrated to me that there while
you could go
crazy with triary nesting there should be a better way.
Looked at the
pattern matching proposal and while could possibly help
looked like it
was overkill for the typical use case that I'm seeing. The
most relevant
example I noted was switch expressions from Java. When
applied to this
problem really create a simple result:
const category = data.category || switch
(setting.incomeCode) {
case TaxIncomeCode.RENTS_14 => PaymentCategory.RENT;
case TaxIncomeCode.ROYALTIES_COPYRIGHTS_12 =>
PaymentCategory.ROYALTIES;
case TaxIncomeCode.INDEPENDENT_PERSONAL_SERVICE_17 =>
PaymentCategory.SERVICES;
default => PaymentCategory.OTHER;
}
Note; the instead of using the '->' as Java, continue to use
=> and with
the understanding that the right hand side is fundamentally
function.
So similar things to this are natural, note this proposal
should remove
"fall through" breaks and allow for multiple cases as such.
const quarter = switch (foo) {
case "Jan", "Feb", "Mar" => "Q1";
case "Apr", "May", "Jun" => "Q2";
case "Jul", "Aug", "Sep" => "Q3";
case "Oct", "Nov", "Dec" => { return "Q4" };
default => { throw new Error("Invalid Month") };
}
Also compared this to the do expression proposal, it also
provides a
substantial simplification, but in a way that is more
consistent with
the existing language. In one of their examples they provide
an example
of the Redux reducer
https://redux.js.org/basics/reducers#splitting-reducers --
this would be
a switch expression implementation.
function todoApp(state = initialState, action) => switch
(action.type) {
case SET_VISIBILITY_FILTER => { ...state,
visibilityFilter:
action.filter };
case ADD_TODO => {
...state, todos: [
...state.todos,
{
text: action.text,
completed: false
}
]
};
case TOGGLE_TODO => {
...state,
todos: state.todos.map((todo, index) => (index ===
action.index) ? { ...todo, completed: !todo.completed } : todo)
};
default => state;
}
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
