• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Sun Should Remove 'void' As A Return Type?

 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is just a random thought I had today while programming. Pure opinion and I'm just looking for some feedback. Call it Friday Drivel, but with meaning.

I think that rather than 'void' return types objects should return an instance of themselves. Mind you, if it is already returning a non-void type then that is fine. Since using jquery quite a bit I have fallen in love with chaining. Most Java objects don't allow chaining at all. At least not in the core API. For example:



I'd rather do this:



Obviously I could (and did) write my own class to accomplish this. I guess the real question is what does 'void' gain us? Is there anytime when 'void' is the only logical return type?
[ August 22, 2008: Message edited by: Gregg Bolinger ]
 
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Nice "stir the pot" subject heading.

I have a problem with void methods too but for a different reason. I prefer to write code with as few visible side effects as possible, and a void return type is the antithesis of that goal.

I do agree that classes like StringBuilder/Buffer and Scanner which return themselves with every method invocation, are nice to code to. I still cringe a little when I use them because they are still at their core heavily dependent on side effect to do their job.
 
Bartender
Posts: 4179
22
IntelliJ IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gregg Bolinger:
Is there anytime when 'void' is the only logical return type?



To play Devil's Advocate I have tried to come up with a reason. I have yet to think of one, but I will keep trying :-)

Originally posted by Garrett Rowe:
I have a problem with void methods too but for a different reason. I prefer to write code with as few visible side effects as possible, and a void return type is the antithesis of that goal.



I am not sure exactly what you mean. Can you define what side effects you are talking about?

Originally posted by Garrett Rowe:
I do agree that classes like StringBuilder/Buffer and Scanner which return themselves with every method invocation, are nice to code to. I still cringe a little when I use them because they are still at their core heavily dependent on side effect to do their job.



But if the 'side effects' are what we depend on to do the job, aren't the 'side effects' the 'effects (goals)' not 'side effects'? Or am I missing something?
 
Garrett Rowe
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I mean side-effect in the sense that operations on Strings don't have side effects but operations on StringBuilders do, since StringBuilders are designed to be mutable:



The internal state of the String is not modified by the call to concat, it never will be because Strings are designed to be side-effect free. The internal state of the StringBuilder object is modified by the call to append, that's the side-effect.
[ August 22, 2008: Message edited by: Garrett Rowe ]
 
Steve Luke
Bartender
Posts: 4179
22
IntelliJ IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ahh, I see. So any mutable object that you would use would have side effects (state change). And now it makes sense that you would have problems with void methods, since they would almost by definition change state of the object they are called on.

Funny I had never heard state-change referred to as a side-effect (at least not that I recognized).
 
Bartender
Posts: 2856
10
Firefox Browser Fedora Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes I remember using void functions in C that just used to print out linked lists (although an int type was expected that should return 0 for success and 1 for failure, although we never did it ).

Maybe it is used to parallel procedures in other programming languages like VB and Pascal(Delphi).

Another possible scenario is the void pointer in C which can be typecasted into any other type.

In Java void is mostly associated with Javabean setter methods and other similar methods.
But still I cant think of a scenario where using the void return type cant be avoided.But that would mean that the function is forced to return atleast an int, even if it simply setting a variable or printing a object.
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your idea is not new, this has been discussed on The Java Posse before. See this for some more info:

RFE: Method chaining for instance methods that return void

Method Chaining (Martin Fowler)
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Garrett, I assume you have experience with functional programming languages?
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jesper Young:
Your idea is not new, this has been discussed on The Java Posse before. See this for some more info:

RFE: Method chaining for instance methods that return void

Method Chaining (Martin Fowler)



Cool, thanks.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I like method chaining when it is useful. For some objects chaining makes more sense to me than others. Particularly small objects with only one or two methods, chaining doesn't have much use.

My first reaction was that I like when IDEs/static analysis tools warn against ignored return values. (They add the common classes with chaining to an exclude list.) My second reaction was that they could rewrite the rules to not flag methods returning their class type. My third reaction is that not assigning the result of a string.replaceAll() type method is a common error and it is important to flag. My fourth reaction is that they could not exclude String.

I guess I'm kind of on the fence. I'm sure it'll never happen so no worries there .
 
Garrett Rowe
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
Garrett, I assume you have experience with functional programming languages?



Experience would probably be overstating it. I've played around with Haskell and more recently Scala, and I've lurked around Lambda the Ultimate and read a lot of papers referenced there and even understood a few of them.
[ August 23, 2008: Message edited by: Garrett Rowe ]
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I completely understand where Gregg is coming from. Having been involved in a lot of JavaScript programming using jQuery (which almost forces you to use JavaScript as the functional language it was intended as) over the past year or so, when writing Java, I not only miss the chaining that he mentioned, but the whole concept of closures and functions as first-class objects.

Of course when writing JavaScript, there are some Java concepts that I miss too...
 
Rancher
Posts: 4803
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And in Smalltalk, everything is an object, and every "function" returns an object.

The reality is that Java was invented with a number of crutches from C, to ease acceptance. 'void' returns is not as ugly to my eyes as int, float, etc.
being non-Objects
 
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I reckon, SUN made void that way to maintain the consistency of the syntax ("a function MUST have a return type explicitly set")

Consistent syntax means it is easier for non-human (i.e programs) to understand, as less 'exception' is needed to parse it. In a way, I believe this helps in the IDE department.

I used to loathe this verbose culture of the java language - but over time working with various systems, I think it actually contributes to the supportability / maintainability of a system.

I've worked with C, C++ and python system where a function signature could look like this:



Whereas code like that is not impossible in Java, but it just doesn't align with the whole culture of the language.

So the whole 'void' thing does not really add any direct benefit, but it's part of Java's 'spirit of verbosity' - which I kind of love and hate, but seems to fit in where they belong.

So personally I don't see any reason as to why the void should be removed from the Java syntax. It fits nicely with the language!

However, I do see the (good) sense behind recent momentum around things like Groove, Scala, and even Jython as an alternative way to brewing Java in a non restrictive syntax. And it's good because this is done in a completely separate thing (instead of it being another incarnation of Java... we have enough variety with J2ME, J2SE, J2EE already!)
[ August 24, 2008: Message edited by: Zenikko Sugiarto ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not sure that void needs to be removed from the language. I am a friend of fluent interfaces, though. Especially for Builders, they make a heck lot of sense.
reply
    Bookmark Topic Watch Topic
  • New Topic