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
<https://github.com/tc39/proposal-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
<https://github.com/tc39/proposal-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
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
