Assigning void

[Wojtek]

Lew wrote :

First of all, asking unanswerable
questions is not /per se/ trolling.

I have always considered "trolling" to be making an obnoxious post
which is designed to inflame someone into making a contradictory post.
Hopefully many someones.

Asking a "quiet" question which may/may not be answerable is hardly
trolling.

Or, I am not trying to kick the cat, just tickle it a little.

 

[Jeff Higgins]

I think the author is questioning, why this statement is only usable as
an assignment statement.

Yes you don't it, as you could refactor the code like this:

ftp.enterMode(
server.getConnectionType() == ACTIVE ? Mode.LOCAL_ACTIVE
: Mode.LOCAL_PASSIVE
);

But still I fancy the idea to be able to write:

purse.isEmpty() ? goHome() : goToTheMovies();
as a shorthand for:
if (purse.isEmpty()) goHome(); else goToTheMovies();

What would be wrong about that?

According to others in parallel threads it's all wrong.
I agree it would be pretty.

 

[Eric Sosman]

[...]
But still I fancy the idea to be able to write:

purse.isEmpty() ? goHome() : goToTheMovies();
as a shorthand for:
if (purse.isEmpty()) goHome(); else goToTheMovies();

What would be wrong about that?

(purse.isEmpty()
? new Runnable() {
@Override
public void run() {
goHome();
}
}
: new Runnable() {
@Override
public void run() {
goToTheMovies();
}
}
).doIt();

Problem solved!

 

[Jeff Higgins]

Lew wrote :

I have always considered "trolling" to be making an obnoxious post which
is designed to inflame someone into making a contradictory post.
Hopefully many someones.

Asking a "quiet" question which may/may not be answerable is hardly
trolling.

Or, I am not trying to kick the cat, just tickle it a little.

My vision of a troll is someone stopping passersby
upon a bridge with the intent to exact a toll.
In the case of usenet the bridge is communication.
Your post does not appear to be a troll.
I also don't see your post as an "unanswerable question".

 

[Jeff Higgins]

I suppose that would have been better phrased as:
" ... why it couldn't be ...".
But then I might be accused of trolling
by way of an unanswerable question.

Whether it could have been, the history of the ternary ?: operator has been
solely as an expression,

I guess I'll have to trust you here.
I haven't attempted to trace the history.

although this is muddied in languages that permit
standalone expressions.

I think you begin to muddy the question here.
I haven't asked why not permit standalone expressions.
Only why boolean expression ? block : block ;
could not stand in for an if-then-else statement.
I understand that it *cannot* because of the specification.

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?

See above.

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

I don't understand. If a program statement changes
the state of the program then it is an imperative statement?

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

I don't see it.

Is that a good idea?

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

I agree it will likely not happen.
Not sure about the other.

Now that you know why,
?;

the debate is open as to whether the reason is
compelling.

Yep.

 

[Jeff Higgins]

I suppose that would have been better phrased as:
" ... why it couldn't be ...".
But then I might be accused of trolling
by way of an unanswerable question.


I guess I'll have to trust you here.
I haven't attempted to trace the history.


I think you begin to muddy the question here.
I haven't asked why not permit standalone expressions.
Only why boolean expression ? block : block ;
could not stand in for an if-then-else statement.
I understand that it *cannot* because of the specification.


See above.


I don't understand. If a program statement changes
the state of the program then it is an imperative statement?

Ah, Ok. I had to go back an look up side effect.
In my new language :
boolean expression ? block : block ;
is simply an if-then-else statement
not an assignment expression so no *side* effect
is possible only an effect.

 

[Jeff Higgins]

From what I gather from this thread so far
there is no technical reason for not being able
to share the ?: syntax between the conditional
operator and an if-then-else statement.
If Larry Ellison walked into the shop Monday
morning and announced "I would like a
'boolean expression ? block : block' syntax
in the Java language" he would not be met with
a chorus of "It cannot be done".

 

[Eric Sosman]

[...]
But still I fancy the idea to be able to write:

purse.isEmpty() ? goHome() : goToTheMovies();
as a shorthand for:
if (purse.isEmpty()) goHome(); else goToTheMovies();

What would be wrong about that?

(purse.isEmpty()
? new Runnable() {
@Override
public void run() {
goHome();
}
}
: new Runnable() {
@Override
public void run() {
goToTheMovies();
}
}
).doIt();

Problem solved!

... once the method name in the final line is changed from
`doIt' to `run'. >Sigh< The perils of making "clarifying edits"
without similar attention to proofreading ...

 

[Roedy Green]

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.

the ? : operator requires values. Even if you could trick the
compiler into accepting that, it would be a nutty idea because it
would confound fellow programmers reading your code.

 

[Robert Klemme]

markspace wrote:

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".

My memory might be a bit rusty but the definition of "side effect" that
I learned was that it is a state change not reflected in the result.
That includes IO for example, even if one could argue that the main
effect of System.out.println("foo") is to print "foo\n" on the console.
The definition of "side effect" I have in mind solely deals with a
distinction important in the context of functional languages. A side
effect free expression has some properties which go away when side
effects are introduced (thread safety, stability which has effects on
analysis of behavior etc.). The introductory paragraph on the Wikipedia
page nicely sums this:
http://en.wikipedia.org/wiki/Side_effect_(computer_science)

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

Yes, because variable assignment changes state. If you think about it,
statements in languages which have statements (additionally to
expressions) only make sense at all if there are side effects. A
statement (which doesn't have a result) in a language completely free of
side effects would do nothing - ever.

Kind regards

robert

 

[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...

Summing up.
The kitty tickled is now resting content and secure in her favored JLS.
The poor maligned compiler is only performing as her implementers
have been allowed by the language specifiers.
Stylistically, some would accept the put forth construct; others not.

 

[Lew]

My memory might be a bit rusty but the definition of "side effect" that
I learned was that it is a state change not reflected in the result.
That includes IO for example, even if one could argue that the main
effect of System.out.println("foo") is to print "foo\n" on the console.
The definition of "side effect" I have in mind solely deals with a
distinction important in the context of functional languages. A side
effect free expression has some properties which go away when side
effects are introduced (thread safety, stability which has effects on
analysis of behavior etc.). The introductory paragraph on the Wikipedia
page nicely sums this:

http://en.wikipedia.org/wiki/Side_effect_(computer_science)

As a term of art, its definition as you state it I cannot dispute.

As a term of common English, a "side" effect is something different from the
stated, explicit purpose.

In medicine they say, "There are no side effects, only effects."

I should have used the term of art, but I was actually saying "side effecty",
not "side effect", even to including the quotes, so I explicitly avoided the
term of art.

I admit I should have used a clearer term, but I was using the term introduced
in the post to which I responded.

My point is that assignment isn't a "side effect" (ordinary English) of
auto-increment, but the intended effect. In the context of why assignment and
its siblings can constitute a statement, but not '?:' or '+', it makes sense.

Thank you for distinguishing this from the term of art.

 

[Gene Wirchenko]

From what I gather from this thread so far
there is no technical reason for not being able
to share the ?: syntax between the conditional
operator and an if-then-else statement.
If Larry Ellison walked into the shop Monday
morning and announced "I would like a
'boolean expression ? block : block' syntax
in the Java language" he would not be met with
a chorus of "It cannot be done".

So what?

If he walked into the shop and announced that he was going to
hang himself, the same would apply.

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

Lew wrote :

I have always considered "trolling" to be making an obnoxious post
which is designed to inflame someone into making a contradictory post.
Hopefully many someones.

Asking a "quiet" question which may/may not be answerable is hardly
trolling.

No. It is not whether the question is quiet or not that
determines whether the post is trolling; it is the desired effect that
determines.

Or, I am not trying to kick the cat, just tickle it a little.

Fluffy says, "Scratch behind my right ear, please."

Sincerely,

Gene Wirchenko

 

[Jukka Lahtinen]

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

But 'then' is not Java.

 

[Lew]

Right - '{' and '}' are four keys. Sorry.

But 'then' is not Java.

I have no excuse. The only reason I can imagine for this is that I have
been doing a lot of bash coding lately. But still.

Another point I should clarify - "operator" is not a sufficient distinction.

I should have said "simple operator" or some such phrase to distinguish
operators like the ternary one here, the arithmetic operators, comparison
operators and the like, whose purpose is not to cause a state change but to
produce a value.

It's pretty clear that the Java designers viewed these categories of operators
differently, as that difference is codified in the language.

 

[Joerg Meier]

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

I know it's been a few days, but I just read this and wanted to add that I
find the above expression pretty horrible, as I could not without
experimentation or study of the JLS tell how that would turn out - could be
either

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

or

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

maybe that's just me, though.

Liebe Gruesse,
Joerg

 

[Sven Köhler]

Am 13.10.2012 07:54, schrieb Wojtek:

but I want to do:

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

That's not correct Java syntax. Live with it.

 

[Peter J. Holzer]

It can't be that one. That expression doesn't compile, because the literal
"1" is not a boolean value, nor is "(a < b)" an integer value, and so "1 :
(a < b)" is not a valid portion of a ?: operator expression (i.e. the two
possible results don't match in type, nor are convertible to each other's
type).

True. However, in C there is (was) no boolean type so the precedence
could still be the wrong way around (requiring extra parentheses in
Java).

However, the inventors in C did spend some time contemplating typical
uses before deciding on the precedence of the operators, and they
expected that nesting ?: like this:

cond1 ? value1 :
cond2 ? value2 :
cond3 ? value3 :
value4

would be a typical use and chose the precedence and associativity to
allow this without extra parentheses.

hp

 

[glen herrmannsfeldt]

(snip)

However, the inventors in C did spend some time contemplating typical
uses before deciding on the precedence of the operators, and they
expected that nesting ?: like this:

cond1 ? value1 :
cond2 ? value2 :
cond3 ? value3 :
value4

would be a typical use and chose the precedence and associativity to
allow this without extra parentheses.

I suppose, but some of the C precedence rules are the result of
the late addition of the logical operators && and ||.

Previously, the & and | operators were used, and they kept their
precedence even after && and || were added.

-- glen