Re: [ljc] Return types

From: Wesley H.
Sent on: Wednesday, February 13, 2013 1:14 AM
<Columbo>Oh, and just one more thing...</Columbo>

If you plan to use some pretty standard frameworks, (a certain one *springs* to mind...), then you will find a lot of ingrained support for the Java Beans convention of mutators of the form 'public void setX(X)'. 

This convention is everywhere, and I am fairly certain these frameworks are going to barf badly if you start expressing mutators that actually return a value (even if it's Void). You will quickly find that you are having to write your own data binding and serialization/deserialization libraries because none of the 'off the shelf' ones, support your conventions. 



On Wed, Feb 13, 2013 at 12:55 AM, Wesley Hall <[address removed]> wrote:
I am going to add my +1 for the 'bamboozled' response. 

This is a very strange practice, and I don't really buy any of your justifications. 

Primitive types are actually pretty useful when there is a need to express (the pretty common) requirement that a value should be non-null. Presumably you are interfacing with a lot of libraries (most notably that JDK libraries) which use primitives liberally so you are relying on a lot of automatic type conversions and have to do a lot of null checks to avoid NPEs. 

Your code is actually less type safe, because toTask().toString() will compile and then crap out at runtime with an NPE, where, if you were using void methods this would be a compile error. 

Reflection, for the most part, is exactly the same. Reflectively invoking doTask() will return null whether you use your pattern or a standard void method. Primitives are wrapped for reflection stuff, but "doing even more wrapping, manually", doesn't really seem like an optimal solution. If you are doing a tonne of reflection, you might want to consider running Java 7 and taking a look at the MethodHandle api... which provides a much nicer reflective API, though I hope you are doing reflection only where absolutely required. Overuse of reflection isn't exactly a big win for type safety either.

You seem to be saving vertical space by writing methods that take Object arguments that they don't use. Presumably 'runStuff' takes a single Object param (or worse, an Object var arg), that it completely ignores. It has no choice really because it can't do much with an Object reference and can't cast because it never knows what it will be getting.

If you are really worried about vertical space saving (and it seems to be a trivial problem to me)... then why not...

doTask(); runStuff();

This reads much better in immediately telling me that runStuff doesn't depend doTask, and I can tell this without having to go an read the runStuff method source to see that it is just taking an ignored parameter. It also makes it visually clear which order these side-effect methods will run in. Left to right works much better for those of us who are not fluent in Arabic ;). 

In case it is not obvious by this point. You don't have my vote ;).

I fully support your deviants (who are actually not so deviant) ;).

Wes

On Tue, Feb 12, 2013 at 8:14 PM, Jonathan McNealy <[address removed]> wrote:
Hi guys,

We've been debating this for a while here, and we can't decide between the following two development methodologies with respect to the return statement.

It's currently policy to write functions that don't return a value like this:

public Void doTask() {
  ...

  return null;
}

this is best because:
- everything should be an object (Integer instead of int, and so on)
- it's type-safe
- reflection is more consistent, as the primitive/object difference api is a pain
- allows multiple calls on one line (saving vertical space, e.g. return runStuff(doTask()))

however some of the newcomers to the company are rather dismissive of the benefits of Void, and insist of the following nasty and inconsistent way of doing it:

public void doTask() {
  ...

  return;
}

and some deviants even insist on removing the return statement:

public void doTask() {
  ...
}

!!

I'm currently in the process of writing up a JSR to only support the Void/return null pattern, as it's clearly the most consistent and only having one way of doing something is the best approach, however I'm curious as to what the community thinks about the issue.

Please don't cheat by casting your vote more than once!

Kind regards

J.





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Jonathan McNealy ([address removed]) from LJC - London Java Community.
To learn more about Jonathan McNealy, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]


Our Sponsors

  • Our Blog

    Read the latest news from the LJC

  • RecWorks Ltd

    Fixing Tech Recruitment using the Power of Community

  • jClarity

    Java/JVM Performance Analysis Tools & mentoring for Java related matters

  • LJC Aggrity

    Our LJC Aggrity site contains blog posts from our members

  • LJC Book Club

    Our Book club with book reviews from our members

  • Devoxx UK

    Java Community Conference, in collaboration with the LJC 12/13 Jun 14

  • SkillsMatter

    "Host, help organise, promote, film many of our meetings."

  • New Relic

    New Relic makes sense of billions of metrics a day in real time.

  • Hazelcast

    Hazelcast is the leader in operating in-memory computing.

  • Packt Publishing

    A publishing company specializing on specific technologies and solutions

  • Java.Net

    We are an official Java User Group recognised by Oracle's JUG program

  • JRebel

    Free 3 month J-Rebel license.

  • O'Reilly

    40% discount on printed books and 50% on e-books.

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy