This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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 ]
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.
Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. - Laurence J. Peter
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?
Joined: Jan 17, 2006
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 ]
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).
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.
Garrett, I assume you have experience with functional programming languages?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
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 .
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 ]
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 ]
Joined: Jul 11, 2001
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.
subject: Sun Should Remove 'void' As A Return Type?