Assigning void

[Wojtek]

I can legally do the following:

if (server.getConnectionType() == ConnectionType.ACTIVE)
ftp.enterLocalActiveMode();
else
ftp.enterLocalPassiveMode();

but I want to do:

(server.getConnectionType() == ConnectionType.ACTIVE) ?
ftp.enterLocalActiveMode() : ftp.enterLocalPassiveMode();

However the compiler insists that I must have an assignment even though
both ftp methods return void. I would think that the compiler would be
smart enough to realize that nothing CAN be returned.

Oh yes, I am using Eclipse with Java 7

Thoughts? I mean other than stylistic comments...

 

[Lew]

I can legally do the following:

if (server.getConnectionType() == ConnectionType.ACTIVE)
ftp.enterLocalActiveMode();
else
ftp.enterLocalPassiveMode();

but I want to do:

(server.getConnectionType() == ConnectionType.ACTIVE) ?
ftp.enterLocalActiveMode() : ftp.enterLocalPassiveMode();

However the compiler insists that I must have an assignment even though
both ftp methods return void. I would think that the compiler would be
smart enough to realize that nothing CAN be returned.

Oh yes, I am using Eclipse with Java 7

Thoughts? I mean other than stylistic comments...

The compiler is smart enough to realize that nothing can be returned.

It's also smart enough to realize that standalone expressions, such
as this one or a lone 'x', are not legal.

http://docs.oracle.com/javase/specs/jls/se7/html/jls-14.html#jls-14.8
and the rest of Chapter 14.

 

[Eric Sosman]

I can legally do the following:

if (server.getConnectionType() == ConnectionType.ACTIVE)
ftp.enterLocalActiveMode();
else
ftp.enterLocalPassiveMode();

but I want to do:

(server.getConnectionType() == ConnectionType.ACTIVE) ?
ftp.enterLocalActiveMode() : ftp.enterLocalPassiveMode();

However the compiler insists that I must have an assignment even though
both ftp methods return void. I would think that the compiler would be
smart enough to realize that nothing CAN be returned.

Oh yes, I am using Eclipse with Java 7

Thoughts? I mean other than stylistic comments...

http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.25

.... with special attention to the second BOLDFACE sentence.

 

[Jeff Higgins]

13.10.2012 08:54, Wojtek kirjoitti:

Why do you want to use an assignment statement without need or means to
assign anything to anywhere?

I'm guessing he doesn’t.

What's the rationale?

I'm guessing his eye beholds beauty in the latter.

 

[Jeff Higgins]

I can legally do the following:

if (server.getConnectionType() == ConnectionType.ACTIVE)
ftp.enterLocalActiveMode();
else
ftp.enterLocalPassiveMode();

but I want to do:

(server.getConnectionType() == ConnectionType.ACTIVE) ?
ftp.enterLocalActiveMode() : ftp.enterLocalPassiveMode();

However the compiler insists that I must have an assignment even though
both ftp methods return void. I would think that the compiler would be
smart enough to realize that nothing CAN be returned.

Oh yes, I am using Eclipse with Java 7

Thoughts? I mean other than stylistic comments...

Others have pointed you to the specification.
I don't know why it can't be a shorthand if-then-else statement too.

 

[glen herrmannsfeldt]

(snip)

(snip)

Others have pointed you to the specification.
I don't know why it can't be a shorthand if-then-else statement too.

Java isn't C.

Java allows for method calls that return a value to ignore the
return value, but other expressions that don't use the value
seem not to be allowed.

2+2;

is legal C, but not Java.

-- glen

 

[Jeff Higgins]

(snip)


Java isn't C.

Java allows for method calls that return a value to ignore the
return value, but other expressions that don't use the value
seem not to be allowed.

2+2;

is legal C, but not Java.

C has its Rationale.
Java seems not to have a separate formal one.
6.5.15 of the C Rationale only states
the construct is allowed and not why.
15.25 of the Java Spec. only states
the construct is disallowed and not why.
Does it sound childish to ask why?

 

[markspace]

both ftp methods return void. I would think that the compiler would
be smart enough to realize that nothing CAN be returned.

Does it sound childish to ask why?

The way the OP puts it, yes, it comes across as a bit childish. The OP
didn't ask "why," he asked for "thoughts." My thought is "read the JLS."

I realize *you* asked why, but in the vein of the OP's premise, I feel
"read the spec" is a valid answer. "Why" requires reading someone's
mind, and time travel. Since those are obviously impossible, the result
borders on trolling.

I'd guess that the original intent and the current thinking is that Java
should be "easy to read" and that shortening branch flow to a single
character pushes somebody's Perl buttons, but that's a total guess.

What about this:

(some large expression || some other large expression )
? {
Statement;
Statement;
Statement;
} : {
Statement;
Statement;
Statement;
}

? Do we really want to go there?

 

[Jeff Higgins]

C has its Rationale.
Java seems not to have a separate formal one.
6.5.15 of the C Rationale only states
the construct is allowed and not why.
15.25 of the Java Spec. only states
the construct is disallowed and not why.
Does it sound childish to ask why?

Don't get me wrong. I understand that in both
languages this construct is the conditional "operator".
I'm asking only why it cannot also be shorthand for
an if-then-else statement.
boolean expression ? block : block

 

[Jeff Higgins]

The way the OP puts it, yes, it comes across as a bit childish. The OP
didn't ask "why," he asked for "thoughts." My thought is "read the JLS."

I realize *you* asked why, but in the vein of the OP's premise, I feel
"read the spec" is a valid answer. "Why" requires reading someone's
mind, and time travel. Since those are obviously impossible, the result
borders on trolling.

I'd guess that the original intent and the current thinking is that Java
should be "easy to read" and that shortening branch flow to a single
character pushes somebody's Perl buttons, but that's a total guess.

What about this:

(some large expression || some other large expression )
? {
Statement;
Statement;
Statement;
} : {
Statement;
Statement;
Statement;
}

? Do we really want to go there?

I suppose it would be allowed in my
boolean expression ? block : block ;
and would probably be ugly per your example.

But I think
(server.getConnectionType() == ConnectionType.ACTIVE) ?
ftp.enterLocalActiveMode() : ftp.enterLocalPassiveMode();
would be pretty.

 

[Wojtek]

markspace wrote :

The way the OP puts it, yes, it comes across as a bit childish. The OP
didn't ask "why," he asked for "thoughts." My thought is "read the JLS."

Hmm, I wasn't questioning the compiler as I would hope it follows the
JLS.

Yes, I have a C background, and I have used this expression many times,
and indeed I have nested it several layers deep, since it made most
sense (to me) to do so.

I realize *you* asked why, but in the vein of the OP's premise, I feel "read
the spec" is a valid answer. "Why" requires reading someone's mind, and time
travel. Since those are obviously impossible, the result borders on
trolling.

So questioning a design decision and trying to understand its rational
is trolling? Really?

I'd guess that the original intent and the current thinking is that Java
should be "easy to read" and that shortening branch flow to a single
character pushes somebody's Perl buttons, but that's a total guess.

There are many ways and many people who try to write code which is easy
to read. Anyone can write obfuscated code, but seasoned coders tend to
try to simplify where possible, not use clever tricks, at least IMHO.

What about this:

(some large expression || some other large expression )
? {
Statement;
Statement;
Statement;
} : {
Statement;
Statement;
Statement;
}

Interesting. I had not followed the idea that far. Though in common use
it really just replaces a succinct if/else construct.

 

[Wojtek]

Lew wrote :

The compiler is smart enough to realize that nothing can be returned.

It's also smart enough to realize that standalone expressions, such
as this one or a lone 'x', are not legal.

http://docs.oracle.com/javase/specs/jls/se7/html/jls-14.html#jls-14.8
and the rest of Chapter 14.

I had not considered it to be an expression, though thinking about it
now, it would have to be.

But it is kind of special in that any assignment is conditional, so it
could have special rules.

 

[Lew]

Others have pointed you to the specification.
I don't know why it can't be a shorthand if-then-else statement too.

Whether it could have been, the history of the ternary ?: operator has been
solely as an expression, although this is muddied in languages that permit
standalone expressions.

Java chose to prohibit standalone expressions. Having ?: work as a statement

x ? 3 : 4;

is no better or worse than would any other expression

3 + 4;

Java banned the latter, perforce the former.

You asked why. The reason is consistency. Why shouldn't expressions work
as standalone statements generally, as in C? I guess it's to do with the
philosophy that side effects by themselves are not imperatives.

In any event, to make the ternary ?: a "shorthand if-then-else statement"
requires we make every expression a statement. Is that a good idea?

As it's oppositional to the core ontology of Java, it'll never happen.

Now that you know why, the debate is open as to whether the reason is
compelling.

 

[markspace]

So questioning a design decision and trying to understand its rational
is trolling? Really?

Yup, because there's no way anyone on this list could possibly answer
that question. You might try asking some of the language conferences or
at JavaOne. They might be able to tell you, or at least give you a
rational.

All I can personally say, and I'm pretty sure all anyone here can say,
is "Java is easy to read" is a goal, and allowing inline conditional is
seen as detrimental to that goal. Maybe.

 

[Lew]

markspace wrote :

The way the OP puts it, yes, it comes across as a bit childish. The OP
didn't ask "why," he asked for "thoughts." My thought is "read the JLS."

Hmm, I wasn't questioning the compiler as I would hope it follows the
JLS.

Yes, I have a C background, and I have used this expression many times,
and indeed I have nested it several layers deep, since it made most
sense (to me) to do so.

I realize *you* asked why, but in the vein of the OP's premise, I feel "read
the spec" is a valid answer. "Why" requires reading someone's mind, and time
travel. Since those are obviously impossible, the result borders on
trolling.

So questioning a design decision and trying to understand its rational[e]
is trolling? Really?

I'd guess that the original intent and the current thinking is that Java
should be "easy to read" and that shortening branch flow to a single
character pushes somebody's Perl buttons, but that's a total guess.

There are many ways and many people who try to write code which is easy
to read. Anyone can write obfuscated code, but seasoned coders tend to
try to simplify where possible, not use clever tricks, at least IMHO.

What about this:

(some large expression || some other large expression )
? {
Statement;
Statement;
Statement;
} : {
Statement;
Statement;
Statement;
}

Interesting. I had not followed the idea that far. Though in common use
it really just replaces a succinct if/else construct.

How much more succinct?

'if' is two keys plus 'then' is four for six keys. '?' is two keys.

'else' is four keys, ':' is two.

Advantage: '?:' ten to four.
But for clarity, most ternary expressions require a pair of parentheses,
adding four keys. Now the advantage is ten to eight.

And '?:' loses its place as an operator.

Succinctness isn't always better, especially if the difference is this
minor for such a fundamental shift.

 

[markspace]

I guess it's to do with the
philosophy that side effects by themselves are not imperatives.

Sometimes. Voila:

int i = 0;
i++;

I'd consider post-increment there a side effect, yet it's legal. Yes, I
know there's an implied (required) assignment there, but it's still
side-effecty.

 

[Lew]

So questioning a design decision and trying to understand its rational[e]
is trolling? Really?

Yup, because there's no way anyone on this list could possibly answer
that question. You might try asking some of the language conferences or
at JavaOne. They might be able to tell you, or at least give you a
rational[e].

All I can personally say, and I'm pretty sure all anyone here can say,

Nope. I said something different, for example.

is "Java is easy to read" is a goal, and allowing inline conditional is
seen as detrimental to that goal. Maybe.

I'm afraid I disagree with markspace here. First of all, asking unanswerable
questions is not /per se/ trolling. Second, there is much one can say about
the rationale for Java. The Founding Coders have written a lot on the ideas
behind Java, so we aren't reasoning in a vacuum. Furthermore, the rationale
is deduceable from the JLS. Or a rationale is, in any event. It is
straightforward to determine why '?:' cannot be a statement from the cited
JLS references already.

It is clearly part of the rationale of Java that not everything that can be
done should be.

Java prohibits standalone expressions as statements, unlike C.

It's such a fundamental and basic and foundational difference between the
languages that I rarely hear anyone question it. "So Java prohibits
standalone expressions as statements. Big deal."

Fine. Clearly it's part of the rationale of Java that a statement, to be
a statement and not just an expression, must effect something.

What does 'x? 4 : 5' effect?

'?:' is placed in the operators table. Ergo, the rationale not to allow
standalone ternary is the rationale not to allow standalone operators
generally.

Q.E.D.

 

[Lew]

I guess it's to do with the
philosophy that side effects by themselves are not imperatives.

Sometimes. Voila [sic]:

int i = 0;
i++;

I'd consider post-increment there a side effect, yet it's legal. Yes, I
know there's an implied (required) assignment there, but it's still
side-effecty.

No true Scotsman.

It isn't an implied assignment, it's an explicit one.
http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.14.2

Since it's the purpose of the operator, it's not "side effecty", it's
"direct effecty".

Unless assignment through '=' is also "side effecty".

Thus there's a rationale to give auto-inc/decrement the same
statement-blessing effect as regular assignment.

Furthermore, it gets an explicit mention in the JLS to be statement worthy.
[op. cit.]

You can hold it up as a counterexample, but it actually makes my point.
The language goes into such detail to define exactly what constitutes a
statement that, irrespective of our ability to suss it, we can confidently
state that there's a rationale to exclude the rest.

The hypothesis that it's to make statements have an effect seems sound so far.

 

[glen herrmannsfeldt]

(snip on use of expressions as statements)

Don't get me wrong. I understand that in both
languages this construct is the conditional "operator".
I'm asking only why it cannot also be shorthand for
an if-then-else statement.
boolean expression ? block : block

C allows any expression as a statement, no matter how useless.

It is most often used in C to ignore the return value of a
function, not that it is always a good idea. Way too many
programs ignore the return value of fclose() which may be
the only indication that writing to a file failed.

Java special cases the method call, but otherwise doesn't allow
expressions that don't do assignment as statements.
(Read the JLS for more specific details.)

There are other Java restrictions that seem to be there
to encourage better coding. For one, Java requires that the
compiler be able to verify that a scalar variable is
assigned a value before it is used. Most other languages
trust the programmer to get it right, with no guarantees
if it is wrong.

Now, it would have been easier for Java to always initialize
scalar variables to zero/false/null, but that doesn't encourage
good coding practices.

There is always a compromise between generality and readability.

I don't know how many of the Java originators are still around
to ask. If you really want to know, though, that is the way.

-- glen

 

[Wojtek]

markspace wrote :

Yup, because there's no way anyone on this list could possibly answer that
question. You might try asking some of the language conferences or at
JavaOne. They might be able to tell you, or at least give you a rational.

All I can personally say, and I'm pretty sure all anyone here can say, is
"Java is easy to read" is a goal, and allowing inline conditional is seen as
detrimental to that goal. Maybe.

int a = (isTest()) ? 5 : 4;

As opposed to

int a;

if (isTest())
a = 5;
else
a = 4;

Both are perfectly readable, yet I find the ternary expression better.

Or to strech it a little:

int compare = (a > b) ? 1 : (a < b) ? -1 : 0;

------

int compare;

if ( a > b )
compare = 1;
else if ( a < b )
compare = -1;
else
compare = 0;