On Mar 13, 2018, at 2:57 PM, Remi Forax <fo...@univ-mlv.fr> wrote:
>
> it's perhaps me, but i think that Kevin saying that he wants to discourage
> side effects, not disable them, avoiding side effects like it.next() is not
> possible in Java.
>
> We already have this kind of discussion when we have discussed about lambdas,
> lambdas allow side effects but it's discouraged to use lambdas for that.
> And We already have agree that case expressions do not need to capture
> variables, so expression in a case are like expressions in a ?:, you can do
> side effect in them but it's discouraged.
I get that. I'm just pointing out that, though "functional" is a great
code style heuristic, expressions which occur inside of imperative
loops will have to get themselves dirty as they work with loop
control variables. Since imperative loops aren't going away in
the foreseeable future, we have to envision side effects inside
expressions.
This BTW is another similarity between s-switches and e-switches:
They both have a legitimate need to put side effects into local variables.
With s-switches, it is the *only* way to export a value.
With e-switches, *one* value can be exported the nice way via ->.
But with *both* switches it will be common (as it is common now)
to export *multiple* side effects (or one value and one side effect).
My proof point of this is the ubiquity of the pattern a[i++], which
delivers both a value and a side effect.
More detail: Sometimes I write switches which export two or more
values:
String s;
int n;
switch (tag) {
case 0: s = ""; n = -1; break;
case 1: s = "one"; n = 0; break;
default: s = "many"; n = 1; break;
}
As an extension to my point about a[i++], I would expect the freedom
to refactor that as:
String s;
int n = switch (tag) {
case 0: s = ""; break -1;
case 1: s = "one"; break 0;
default: s = "many"; break 1;
}
There is a flexible set of variations of this multiple-value delivery.
The effect into s as a blank variable could just as easily have
been s += "one", where s has a previous value; that's closer
to the i++ in a[i++].
You will say "yuck", so do I. The e-switch refactoring above arguably
reduces the yuck level from the s-switch. And there are probably pretty
variations waiting to be written, if we allow them.
— John
P.S. For thoughts on value-types as cursors, see:
http://cr.openjdk.java.net/~jrose/values/iterator-vs-cursor.html
<http://cr.openjdk.java.net/~jrose/values/iterator-vs-cursor.html>
