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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#19292

Jeff Higgins wrote:
> 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.

-- 
Lew

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

#19296

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

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

#19299

markspace wrote:
> Lew wrote:
>> 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.

-- 
Lew

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

#19323

On 13.10.2012 22:03, Lew wrote:
> markspace wrote:

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

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_%28computer_science%29

> 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

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

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

#19328

On Sunday, October 14, 2012 5:09:31 AM UTC-7, Robert Klemme wrote:
> 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_%28computer_science%29

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.

-- 
Lew

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

#19316

On 10/13/2012 03:38 PM, Lew wrote:
> Jeff Higgins wrote:
>> Others have pointed you to the specification.
>> I don't know why it can't be a shorthand if-then-else statement too.

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.

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

#19318

On 10/13/2012 07:55 PM, Jeff Higgins wrote:
> On 10/13/2012 03:38 PM, Lew wrote:
>> Jeff Higgins wrote:
>>> Others have pointed you to the specification.
>>> I don't know why it can't be a shorthand if-then-else statement too.
>
> 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?

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.

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

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

#19320

>> On 10/13/2012 03:38 PM, Lew wrote:

>>> Whether it could have been, the history of the ternary ?: operator has
>>> been solely as an expression,
 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".

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

#19341

On Sat, 13 Oct 2012 21:01:34 -0400, Jeff Higgins
<jeff@invalid.invalid> wrote:

>>> On 10/13/2012 03:38 PM, Lew wrote:
>
>>>> Whether it could have been, the history of the ternary ?: operator has
>>>> been solely as an expression,
> 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

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

#19322

On Fri, 12 Oct 2012 22:54:57 -0700, Wojtek <nowhere@a.com> wrote,
quoted or indirectly quoted someone who said :

>
>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.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The iPhone 5 is a low end Rolex. 

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

#19324

On 10/13/2012 01:54 AM, Wojtek wrote:
> 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.

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

#19451

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.

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

#19462

Sven Köhler wrote :
> 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.

So you just posted your first message to this group and this is how you 
want to represent yourself?

Of course it is not valid syntax, I was just trying to start a 
discussion about its possible merits.

-- 
Wojtek :-)

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

#19466

On 10/21/2012 5:52 PM, Wojtek wrote:
> Sven Köhler wrote :
>> 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.
>
> So you just posted your first message to this group and this is how you
> want to represent yourself?
>
> Of course it is not valid syntax, I was just trying to start a
> discussion about its possible merits.

     Merits: "If you want Lisp, you know where to find it."

     Seriously, the fact that C permits the ?: operator with void
operands is an historical accident, a holdover from before the days
when `void' came to C.  Java lacks C's historical baggage, so there's
little reason to carry it.  (Java slavishly perpetuates a few of C's
other infelicities, but this one isn't among them.)

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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

#19467

Eric Sosman wrote :
> On 10/21/2012 5:52 PM, Wojtek wrote:
>> Sven Köhler wrote :
>>> 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.
>>
>> So you just posted your first message to this group and this is how you
>> want to represent yourself?
>>
>> Of course it is not valid syntax, I was just trying to start a
>> discussion about its possible merits.
>
>      Merits: "If you want Lisp, you know where to find it."
>
>      Seriously, the fact that C permits the ?: operator with void
> operands is an historical accident, a holdover from before the days
> when `void' came to C.  Java lacks C's historical baggage, so there's
> little reason to carry it.  (Java slavishly perpetuates a few of C's
> other infelicities, but this one isn't among them.)

The funny thing is that I had not ever used a "void" assignment in C. I 
was just coding along and I thought that using the ?: operator would be 
a "neat" thing. Then the compiler complained so I changed it to an 
if/else statement.

But then I started to wonder, so I posted here.

Call it idle curiosity...

-- 
Wojtek :-)

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

#19473

Am 22.10.2012 05:20, schrieb Wojtek:
> The funny thing is that I had not ever used a "void" assignment in C. I
> was just coding along and I thought that using the ?: operator would be
> a "neat" thing. Then the compiler complained so I changed it to an
> if/else statement.

In C, the line "123;" is correct syntax. (At least, gcc allows it. I
didn't do more research.)

In Java, no such thing is allowed. The syntax forbids it. Hence, the ?:
operator must be used in a place, where some sort of value is required.
For example on the right side of an assignment, or a parameter when a
method is called.


Regards,
  Sven

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

#19490

In article <k6232s$tr8$1@dont-email.me>, Eric Sosman (esosman@comcast-
dot-net.invalid) says...

>      Seriously, the fact that C permits the ?: operator with void
> operands is an historical accident

Could you elaborate that in more depth please? What's so bad about it in 
your opinion?

Kind regards,
Wanja

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

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

#19494

On 10/24/2012 4:03 PM, Wanja Gayk wrote:
> In article <k6232s$tr8$1@dont-email.me>, Eric Sosman (esosman@comcast-
> dot-net.invalid) says...
>
>>       Seriously, the fact that C permits the ?: operator with void
>> operands is an historical accident
>
> Could you elaborate that in more depth please? What's so bad about it in
> your opinion?

     To the first question: Original C had no `void' type at all.
When you had a function (Java: "method") that returned nothing,
it was actually written as if it returned `int'.  The caller was
supposed to ignore whatever garbage happened to land in the
"function value goes here" place (often a designated CPU register),
and that was that.

     Since the compiler couldn't tell a sort-of-`int' function
from a really-`int' function, it had to permit calls to either
kind as the second and third operand of the ?: operator -- since
the two kinds were entirely equivalent, there was no way to forbid
the former while allowing the latter.  Some C programmers found
they could use ?: as a sort of "one-line if/then/else", and did
so.  The condensation was occasionally useful in macro expansions,
and besides: We old-line C programmers value terseness above all
else, even speed (and we value both above correctness ;).

     Along came ANSI C, bearing `void' along with other gifts,
and it became possible to distinguish the two kinds of function.
The compiler could squawk if a non-`void' function failed to
return a value, or if a caller tried to use the non-existent
value of a `void' function.  It would also have been possible
to forbid `void' operands for ?:, but one of the Committee's
charges was to invalidate as little existing code as possible.
So they "grandfathered" existing practice by making a special
case: the second and third operands could be compatible types,
or they could both be `void'.  (I think this makes ?: one of
only two C operators that can take a `void' operand, the other
being the , operator.)

     So: The "historical accident" is that `void' was a latecomer,
and the rules were warped to preserve the investment in old code.

     To your second question, I don't think it's as "bad" as all
that, but neither do I think allowing `void' operands is "good."
In Java we can say that all operators take actual values as
their operands and yield actual values as their results, and the
ability to say "all" instead of "all except" seems to me a sign
of cleanliness in the language.  (Note that `new' is not an
operator, but a keyword introducing a "class instance creation
expression," JLS 15.9.  Even [] and (type), which seem very
operator-like to me, are not called "operators" in JLS.)

     Also, it appears that `void' is not a "type" in Java.  That
may be a controversial position (i.e., I may have to eat my
words), but note that `void' is not listed as a type anywhere
in JLS 4.  The description of java.lang.Void says it's a place-
holder for "the Java *keyword* [emphasis mine] void," not for
a type.  So `void' has an entirely different status in Java than
in C, where it's a full-fledged (but rather special) "type."  An
argument that `void' in Java should behave like `void' in C seems
to me to be on shaky ground; one might make a similar argument
about `goto'!

     Finally, Java's lack of a C-style preprocessor removes some
of the incentive for hyper-abbreviated logic.  In C macros one
sometimes has a need to cram what would ordinarily be a statement
into a context where an expression is required, and both the
`void'-operand ?: and , operators are handy for this purpose, if
more than a little obfuscatory.  Take away the preprocessor and
the need for that kind of condensation, and you take away most of
the reasons for not writing if/then/else in the first place.

	private final class FlameResistantSuit
	    extends WhatIWasWearingBefore { ... }

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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

#19495

In article <k69nlo$ev$1@dont-email.me>, Eric Sosman (esosman@comcast-
dot-net.invalid) says...
> 
> On 10/24/2012 4:03 PM, Wanja Gayk wrote:
> > In article <k6232s$tr8$1@dont-email.me>, Eric Sosman (esosman@comcast-
> > dot-net.invalid) says...
> >
> >>       Seriously, the fact that C permits the ?: operator with void
> >> operands is an historical accident
> >
> > Could you elaborate that in more depth please? What's so bad about it in
> > your opinion?

[..]

>      So: The "historical accident" is that `void' was a latecomer,
> and the rules were warped to preserve the investment in old code.

So far so good, "void" was, as many people cite nowadays, a million 
dollar mistake. Still to that point, I find the terse expression quite 
useful.
 
>      To your second question, I don't think it's as "bad" as all
> that, but neither do I think allowing `void' operands is "good."
> In Java we can say that all operators take actual values as
> their operands and yield actual values as their results

Which is violated by the "void" return parameter in the first place, so 
that can't be a sane base for any assumption regarding Java language 
constructs.

> and the ability to say "all" instead of "all except" seems to me a 
> sign of cleanliness in the language.  

Only that we can't say "all" instead of "all except", since Java already 
knows void methods and I don't see that this will change in the near 
future.

[..]

>(Note that `new' is not an
> operator, but a keyword introducing a "class instance creation
> expression," JLS 15.9.  Even [] and (type), which seem very
> operator-like to me, are not called "operators" in JLS.)

I use to regard "new" as a special kind of method call.

>      Also, it appears that `void' is not a "type" in Java.  That
> may be a controversial position (i.e., I may have to eat my
> words), but note that `void' is not listed as a type anywhere
> in JLS 4.  The description of java.lang.Void says it's a place-
> holder for "the Java *keyword* [emphasis mine] void," not for
> a type.  So `void' has an entirely different status in Java than
> in C, where it's a full-fledged (but rather special) "type."  An
> argument that `void' in Java should behave like `void' in C seems
> to me to be on shaky ground; one might make a similar argument
> about `goto'!

However, if Java language designers were, at some point in time, to 
autobox "void" to "Void", having the compiler or JIT generate the 
missing "return null;" calls, which I would like to be honest, then we 
would be back where we started with C: Every method had a return value, 
and the ternary operator would be applicable everywhere.

In case you're interested, here's a blog I once wrote regarding the Void 
class:
> http://brixomatic.wordpress.com/2011/07/17/into-the-void-refining-
java-beans-with-rare-weapons/ <


>      Finally, Java's lack of a C-style preprocessor removes some
> of the incentive for hyper-abbreviated logic.  In C macros one
> sometimes has a need to cram what would ordinarily be a statement
> into a context where an expression is required, and both the
> `void'-operand ?: and , operators are handy for this purpose, if
> more than a little obfuscatory.  Take away the preprocessor and
> the need for that kind of condensation, and you take away most of
> the reasons for not writing if/then/else in the first place.

I do think that the ternary operator for void (or Void) methods can look 
pretty sexy, which means: readable. It could even be more readable and 
more versatile than a switch statement for example:

  order.isPlaced() ? mailCustomer(confirmation(order))
: order.isSent() ? mailCustomer(trackingInfo(order))
: order.isDelivered() ? mailCustomer(thankYouForOrdering(order));
: throw new IllegalStateException(order.toString());

compare that to:
if(order.isPlaced()) mailCustomer(confirmation(order));
else if(order.isSent()) mailCustomer(trackingInfo(order));
else if(order.isDelivered()) mailCustomer(thankYouForOrdering(order));
else throw new IllegalStateException(order.toString());

or
switch(order.getState()){
  case PLACED: mailCustomer(confirmation(order)); 
   break;
  case SENT: mailCustomer(trackingInfo(order));
   break;
  case DELIVERED: mailCustomer(thankYouForOrdering(order));
   break;
  default:
   throw new IllegalStateException(order.toString());
}

I regard the ternary expression more readable.

Note that this is just some stuff that sprung to my mind, I know that 
one could express the same with polymorphism for example.#

Funny thing is: If you made all these methods return "Void" instead of 
void, you could use the ternary operator like this:

Void _ =
  order.isPlaced() ? mailCustomer(confirmation(order))
: order.isSent() ? mailCustomer(trackingInfo(order))
: order.isDelivered() ? mailCustomer(thankYouForOrdering(order))
: throw new IllegalStateException(order.toString());

It's a dirty hack, I know. But it's pretty interesting what you can do, 
if you like.

Kind regards,
Wanja

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

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

#19496

On 10/24/2012 7:02 PM, Wanja Gayk wrote:
> In article <k69nlo$ev$1@dont-email.me>, Eric Sosman (esosman@comcast-
> dot-net.invalid) says...
>> [...]
>>       To your second question, I don't think it's as "bad" as all
>> that, but neither do I think allowing `void' operands is "good."
>> In Java we can say that all operators take actual values as
>> their operands and yield actual values as their results
>
> Which is violated by the "void" return parameter in the first place, so
> that can't be a sane base for any assumption regarding Java language
> constructs.

     I'm not entirely sure what you mean.  A method can be
declared as `void', which (in Java) means it returns nothing
at all, not even some C-ish non-value of a vacuous type.  The
violation you mention escapes my understanding.

>>       Also, it appears that `void' is not a "type" in Java.  That
>> may be a controversial position (i.e., I may have to eat my
>> words), but note that `void' is not listed as a type anywhere
>> in JLS 4.  The description of java.lang.Void says it's a place-
>> holder for "the Java *keyword* [emphasis mine] void," not for
>> a type.  So `void' has an entirely different status in Java than
>> in C, where it's a full-fledged (but rather special) "type."  An
>> argument that `void' in Java should behave like `void' in C seems
>> to me to be on shaky ground; one might make a similar argument
>> about `goto'!
>
> However, if Java language designers were, at some point in time, to
> autobox "void" to "Void", having the compiler or JIT generate the
> missing "return null;" calls, which I would like to be honest, then we
> would be back where we started with C: Every method had a return value,
> and the ternary operator would be applicable everywhere.

     "Things would be so di-if-fe-rent,
      If they were not as they are!"
      -- Anna Russell
      (Extra credit if you know the tune.)

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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

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

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

csiph-web