Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #19275 > unrolled thread

Assigning void

Back to article view | Back to comp.lang.java.programmer

Contents

  Assigning void Wojtek <nowhere@a.com> - 2012-10-12 22:54 -0700
    Re: Assigning void Lew <lewbloch@gmail.com> - 2012-10-12 23:27 -0700
      Re: Assigning void Wojtek <nowhere@a.com> - 2012-10-13 12:35 -0700
    Re: Assigning void Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-13 09:26 -0400
    Re: Assigning void Donkey Hottie <donkey@fredriksson.dy.fi> - 2012-10-13 17:06 +0300
      Re: Assigning void Jeff Higgins <jeff@invalid.invalid> - 2012-10-13 10:34 -0400
      Re: Assigning void Wanja Gayk <brixomatic@yahoo.com> - 2012-10-13 22:33 +0200
        Re: Assigning void Jeff Higgins <jeff@invalid.invalid> - 2012-10-13 17:34 -0400
        Re: Assigning void Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-13 17:45 -0400
          Re: Assigning void Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-13 21:35 -0400
          Re: Assigning void Wanja Gayk <brixomatic@yahoo.com> - 2012-10-16 00:16 +0200
    Re: Assigning void Jeff Higgins <jeff@invalid.invalid> - 2012-10-13 11:59 -0400
      Re: Assigning void glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-10-13 17:05 +0000
        Re: Assigning void Jeff Higgins <jeff@invalid.invalid> - 2012-10-13 14:26 -0400
          Re: Assigning void markspace <-@.> - 2012-10-13 11:51 -0700
            Re: Assigning void Jeff Higgins <jeff@invalid.invalid> - 2012-10-13 15:08 -0400
            Re: Assigning void Wojtek <nowhere@a.com> - 2012-10-13 12:28 -0700
              Re: Assigning void markspace <-@.> - 2012-10-13 12:42 -0700
                Re: Assigning void Lew <lewbloch@gmail.com> - 2012-10-13 12:54 -0700
                  OT - Trolling Wojtek <nowhere@a.com> - 2012-10-13 14:16 -0700
                    Re: OT - Trolling Jeff Higgins <jeff@invalid.invalid> - 2012-10-13 18:09 -0400
                    Re: OT - Trolling Gene Wirchenko <genew@ocis.net> - 2012-10-14 18:47 -0700
                Re: Assigning void Martin Gregorie <martin@address-in-sig.invalid> - 2012-10-13 20:28 +0000
                Re: Assigning void Wojtek <nowhere@a.com> - 2012-10-13 13:31 -0700
                  Re: Assigning void Joerg Meier <joergmmeier@arcor.de> - 2012-10-20 18:00 +0200
                    Re: Assigning void Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-10-20 09:56 -0700
                      Re: Assigning void "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-10-21 13:24 +0200
                        Re: Assigning void Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-10-21 10:23 -0700
                          Re: Assigning void "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-10-22 00:13 +0200
                            Re: Assigning void Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-10-21 16:25 -0700
                              Re: Assigning void "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-10-22 08:43 +0200
                                Re: Assigning void "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-10-22 10:18 +0200
                                  Re: Assigning void Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-10-22 08:14 -0700
                        Re: Assigning void glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-10-21 19:45 +0000
                          Re: Assigning void "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-10-22 00:14 +0200
              Re: Assigning void Lew <lewbloch@gmail.com> - 2012-10-13 12:44 -0700
                Re: Assigning void Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2012-10-15 14:38 +0300
                  Re: Assigning void Lew <lewbloch@gmail.com> - 2012-10-15 09:11 -0700
          Re: Assigning void Jeff Higgins <jeff@invalid.invalid> - 2012-10-13 15:03 -0400
            Re: Assigning void glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-10-13 20:21 +0000
      Re: Assigning void Lew <lewbloch@gmail.com> - 2012-10-13 12:38 -0700
        Re: Assigning void markspace <-@.> - 2012-10-13 12:49 -0700
          Re: Assigning void Lew <lewbloch@gmail.com> - 2012-10-13 13:03 -0700
            Re: Assigning void Robert Klemme <shortcutter@googlemail.com> - 2012-10-14 14:09 +0200
              Re: Assigning void Lew <lewbloch@gmail.com> - 2012-10-14 11:31 -0700
        Re: Assigning void Jeff Higgins <jeff@invalid.invalid> - 2012-10-13 19:55 -0400
          Re: Assigning void Jeff Higgins <jeff@invalid.invalid> - 2012-10-13 20:25 -0400
            Re: Assigning void Jeff Higgins <jeff@invalid.invalid> - 2012-10-13 21:01 -0400
              Re: Assigning void Gene Wirchenko <genew@ocis.net> - 2012-10-14 18:42 -0700
    Re: Assigning void Roedy Green <see_website@mindprod.com.invalid> - 2012-10-14 00:51 -0700
    Re: Assigning void Jeff Higgins <jeff@invalid.invalid> - 2012-10-14 10:40 -0400
    Re: Assigning void Sven Köhler <remove-sven.koehler@gmail.com> - 2012-10-21 01:24 +0200
      Re: Assigning void Wojtek <nowhere@a.com> - 2012-10-21 14:52 -0700
        Re: Assigning void Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-21 20:13 -0400
          Re: Assigning void Wojtek <nowhere@a.com> - 2012-10-21 20:20 -0700
            Re: Assigning void Sven Köhler <remove-sven.koehler@gmail.com> - 2012-10-22 11:12 +0200
          Re: Assigning void Wanja Gayk <brixomatic@yahoo.com> - 2012-10-24 22:03 +0200
            Re: Assigning void Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-24 17:47 -0400
              Re: Assigning void Wanja Gayk <brixomatic@yahoo.com> - 2012-10-25 01:02 +0200
                Re: Assigning void Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-24 20:21 -0400
                  Re: Assigning void Martin Gregorie <martin@address-in-sig.invalid> - 2012-10-25 20:04 +0000
                    (OT) Re: Assigning void Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-25 16:31 -0400
                      Re: (OT) Re: Assigning void Martin Gregorie <martin@address-in-sig.invalid> - 2012-10-25 20:44 +0000
              Re: Assigning void Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-10-25 07:25 -0300
                Re: Assigning void Lew <lewbloch@gmail.com> - 2012-10-25 11:12 -0700
        Re: Assigning void Sven Köhler <remove-sven.koehler@gmail.com> - 2012-10-22 11:01 +0200
        Re: Assigning void Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-10-23 00:38 +0200

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#19312 — Re: OT - Trolling

On 10/13/2012 05:16 PM, Wojtek wrote:
> 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.
>

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

[toc] | [prev] | [next] | [standalone]

#19342 — Re: OT - Trolling

On Sat, 13 Oct 2012 14:16:43 -0700, Wojtek <nowhere@a.com> wrote:

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

     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

[toc] | [prev] | [next] | [standalone]

#19303

On Sat, 13 Oct 2012 12:42:23 -0700, markspace wrote:

> On 10/13/2012 12:28 PM, Wojtek wrote:
> 
>> 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.

There's a big difference:

- a conditional expression can be assigned to a boolean variable or
  consumed by an "if (condition) ..." statement

- but "( cond ? expr : expr)" is a triadic operator that demands a
  conditional expression as its first operand and returns a result. 
  Since Java syntax requires that an expression's result must be
  consumed and not discarded, it follows that the triadic operator
  ( cond ? expr : expr) *MUST* (a) have all three operands supplied 
  and (b) can only appear on the right hand side of an assignment
  statement or somewhere that will consume its result.  For instance, 
  this somewhat contrived example compiles and runs:

public class Triadic
{
   public static void main(String[] args)
   {
      StringBuilder sb = new StringBuilder();;

      if (args.length > 0)
         for (int i = 0; i < ( args[0].equals("four") ? 4 : 10); i++)
            sb.append("*");

      m(args.length > 0 ? sb.toString() : "Args, what args?");
   }

   public static void m(String s)
   {
      System.out.println(s);
      System.exit(0);
   } 
}

  showing that the triadic doesn't *have* to be the rhs of an assignment,
  though it usually will be used that way, as long as its result will be
  used and not discarded.

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#19304

markspace wrote :
> On 10/13/2012 12:28 PM, Wojtek wrote:
>
>> 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.

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;

-- 
Wojtek :-)

[toc] | [prev] | [next] | [standalone]

#19449

On Sat, 13 Oct 2012 13:31:58 -0700, Wojtek wrote:

> 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

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#19450

On Sat, 20 Oct 2012 18:00:23 +0200, Joerg Meier wrote:

> On Sat, 13 Oct 2012 13:31:58 -0700, Wojtek wrote:
> 
>> 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;

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

The ternary operator certainly has the potential for abuse, but I don't
think the expression you're concerned about was actually all that bad.

Pete

[toc] | [prev] | [next] | [standalone]

#19456

On 2012-10-20 16:56, Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
> On Sat, 20 Oct 2012 18:00:23 +0200, Joerg Meier wrote:
>> On Sat, 13 Oct 2012 13:31:58 -0700, Wojtek wrote:
>>> 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;
>
> 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


-- 
   _  | Peter J. Holzer    | Deprecating human carelessness and
|_|_) | Sysadmin WSR       | ignorance has no successful track record.
| |   | hjp@hjp.at         | 
__/   | http://www.hjp.at/ |  -- Bill Code on asrg@irtf.org

[toc] | [prev] | [next] | [standalone]

#19459

On Sun, 21 Oct 2012 13:24:17 +0200, Peter J. Holzer wrote:

> On 2012-10-20 16:56, Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
>> On Sat, 20 Oct 2012 18:00:23 +0200, Joerg Meier wrote:
>>> On Sat, 13 Oct 2012 13:31:58 -0700, Wojtek wrote:
>>>> 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;
>>
>> 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).

Huh?  C != Java.  Deficiencies in C don't cause problems in Java.  Only
deficiencies in Java do (including those Java may have borrowed from
C...but that is not the case here).

Java (and by following Java's lead, C#, and for that matter, other similar
languages) avoid many of the pitfalls C/C++ set out for the unwary
programmer, exactly because it's more rigorous about its type system and
expression rules.

It's one of the main things I love about coding in Java and C#.  Having a
language and run-time that simply prohibit some of the silly typo-related
mistakes that are common in C/C++.  I used to love C/C++ with a passion,
but now every time I have to go back to C/C++, I cringe.

Pete

[toc] | [prev] | [next] | [standalone]

#19463

On 2012-10-21 17:23, Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
> On Sun, 21 Oct 2012 13:24:17 +0200, Peter J. Holzer wrote:
>> On 2012-10-20 16:56, Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
>>> On Sat, 20 Oct 2012 18:00:23 +0200, Joerg Meier wrote:
>>>> On Sat, 13 Oct 2012 13:31:58 -0700, Wojtek wrote:
>>>>> int compare = (a > b) ? 1 : (a < b) ? -1 : 0;
[...might mean...]
>>>> int compare = ((a > b) ? 1 : (a < b)) ? -1 : 0;
>>>
>>> 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).
>
> Huh?  C != Java.  Deficiencies in C don't cause problems in Java.  Only
> deficiencies in Java do (including those Java may have borrowed from
> C...but that is not the case here).

Yes, but the syntax originated in C and Java didn't change it. While
Java did change some aspects (e.g., it allows assignments only at top of
a statement expression, not nested within an expression), it didn't
change the relative precedence or associativity of operators - it didn't
even fix the priority of the bitwise logical operators (which dmr
himself said was wrong in C (as Glen mentioned, it's wrong because the
logical operators && and || were a later addition and by then they
couldn't change an existing operator)). So if dmr had gotten ?: wrong,
Java probably wouldn't have fixed that, either.

	hp


-- 
   _  | Peter J. Holzer    | Deprecating human carelessness and
|_|_) | Sysadmin WSR       | ignorance has no successful track record.
| |   | hjp@hjp.at         | 
__/   | http://www.hjp.at/ |  -- Bill Code on asrg@irtf.org

[toc] | [prev] | [next] | [standalone]

#19465

On Mon, 22 Oct 2012 00:13:17 +0200, Peter J. Holzer wrote:

> Yes, but the syntax originated in C and Java didn't change it. While
> Java did change some aspects [...]

Sorry. I don't see how you can "change some aspects" but still not "change
it".

The given example in Java is crystal clear, given that only one
interpretation of the expression can even compile.

That it's ambiguous in C without knowing of operator precedence is
irrelevant.  It's not ambiguous in Java.

[toc] | [prev] | [next] | [standalone]

#19469

On 2012-10-21 23:25, Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
> On Mon, 22 Oct 2012 00:13:17 +0200, Peter J. Holzer wrote:
>> Yes, but the syntax originated in C and Java didn't change it. While
>> Java did change some aspects [...]
>
> Sorry. I don't see how you can "change some aspects" but still not "change
> it".

Sorry. That should have read:

The syntax of the ConditionalExpression[1] originated in C and Java
didn't change it. While Java did change some aspects of expression
syntax in general ...


> The given example in Java is crystal clear, given that only one
> interpretation of the expression can even compile.
>
> That it's ambiguous in C without knowing of operator precedence is
> irrelevant.  It's not ambiguous in Java.

It could still be an error in Java. Java syntax is fixed. The compiler
doesn't go back and try some other other parse tree if the code violates
some semantic constraint. 

Yes, the code is unambiguous. But it is unambiguous because the syntax
is what it is. And the syntax is what it is because it was the same way
in C. If it had been different in C, it would (probably) also be
different in Java and then the code *wouldn't* compile.

	hp

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


-- 
   _  | Peter J. Holzer    | Deprecating human carelessness and
|_|_) | Sysadmin WSR       | ignorance has no successful track record.
| |   | hjp@hjp.at         | 
__/   | http://www.hjp.at/ |  -- Bill Code on asrg@irtf.org

[toc] | [prev] | [next] | [standalone]

#19471

On 2012-10-22 06:43, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> On 2012-10-21 23:25, Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
>> The given example in Java is crystal clear, given that only one
>> interpretation of the expression can even compile.
>>
>> That it's ambiguous in C without knowing of operator precedence is
>> irrelevant.  It's not ambiguous in Java.
>
> It could still be an error in Java. Java syntax is fixed. The compiler
> doesn't go back and try some other other parse tree if the code violates
> some semantic constraint. 
>
> Yes, the code is unambiguous. But it is unambiguous because the syntax
> is what it is. And the syntax is what it is because it was the same way
> in C. If it had been different in C, it would (probably) also be
> different in Java and then the code *wouldn't* compile.

Here's an example which (hopefully) illustrates what I mean:

C got the relative precedence of the bitwise operators and the
comparison operators wrong: & has lower precedence than ==, although
that's usually not what you want. That could have been fixed in Java,
but it wasn't. 

So given three int variables a, b, and m, consider this expression:

a & m == b & m

This is parsed as

(a & (m == b)) & m

which then produces the error message

The operator & is undefined for the argument type(s) int, boolean

The compiler can't go back and parse it as

(a & m) == (b & m)

even though that would make sense and is almost certainly what the
programmer meant. That's just not how Java (or any other language with a
context free grammar) works.

So even though one of the interpretations doesn't even compile, the one
which doesn't compile is actually the correct one and the the one which 
would compile is wrong.

	hp


-- 
   _  | Peter J. Holzer    | Deprecating human carelessness and
|_|_) | Sysadmin WSR       | ignorance has no successful track record.
| |   | hjp@hjp.at         | 
__/   | http://www.hjp.at/ |  -- Bill Code on asrg@irtf.org

[toc] | [prev] | [next] | [standalone]

#19476

On Mon, 22 Oct 2012 10:18:43 +0200, Peter J. Holzer wrote:

> [...]
> So even though one of the interpretations doesn't even compile, the one
> which doesn't compile is actually the correct one and the the one which 
> would compile is wrong.

If you see an expression in a working piece of code, it's safe to assume
that it compiles.  That's the case in the _relevant_ example here (i.e. the
one I commented on).  And in that case, the assumption that it compiles
gives you what you need to know to understand it.

[toc] | [prev] | [next] | [standalone]

#19461

Peter J. Holzer <hjp-usenet2@hjp.at> wrote:

(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

[toc] | [prev] | [next] | [standalone]

#19464

On 2012-10-21 19:45, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>> 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. 

Yes. I thought of mentioning that but omitted it for the sake of
brevity.

	hp


-- 
   _  | Peter J. Holzer    | Deprecating human carelessness and
|_|_) | Sysadmin WSR       | ignorance has no successful track record.
| |   | hjp@hjp.at         | 
__/   | http://www.hjp.at/ |  -- Bill Code on asrg@irtf.org

[toc] | [prev] | [next] | [standalone]

#19295

Wojtek wrote:
> markspace wrote :
>> Wojtek wrote:
>>> both ftp methods return void. I would think that the compiler would
>>> be smart enough to realize that nothing CAN be returned.
> 
>> Jeff Higgins wrote:
>>> 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."
> 
> 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.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#19353

Lew <lewbloch@gmail.com> writes:

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

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

-- 
Jukka Lahtinen

[toc] | [prev] | [next] | [standalone]

#19360

Jukka Lahtinen wrote:
> Lew writes:
> 
> > 'if' is two keys plus 'then' is four for six keys. '?' is two keys.

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

>> 'else' is four keys, ':' is two.
> 
> 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. 
 
>> 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.

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.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#19287

On 10/13/2012 02:26 PM, Jeff Higgins wrote:
> On 10/13/2012 01:05 PM, glen herrmannsfeldt wrote:
>> Jeff Higgins<jeff@invalid.invalid> wrote:
>>
>> (snip)
>>
>>>> (server.getConnectionType() == ConnectionType.ACTIVE) ?
>>>> ftp.enterLocalActiveMode() : ftp.enterLocalPassiveMode();
>>
>> (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.
>>
> 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

[toc] | [prev] | [next] | [standalone]

#19302

Jeff Higgins <jeff@invalid.invalid> wrote:

(snip on use of expressions as statements)

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

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

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web