Re: [ljc] Return types

From: user 7.
Sent on: Wednesday, February 13, 2013 10:27 AM
Hi Jon,

You make me cry.

runStuff(doStuff());

If doStuff is actually returning something for runStuff to do something then that would be fine with me, no a null or void object is not something.

I would avoid the inclination to try for conciseness by cramming as much as you can into a space. You achieve conciseness through good generalization and simplification. Let your code breathe:

doStuff();
runStuff();

Believe me, you will need the space to make notes on why you are doing it this way and what the side-effects are.

// This changes the very nature of the universe
doStuff();

// I expect the universe to be very different now
runStuff();

This approach will not be safe if the state is shared with other threads as runStuff most likely relies upon the side-effects of doStuff. 

I would avoid unnecessarily adding boilerplate for little to no tangible benefit, don't do this:

public void doStuff() {
  return null;
}

Or this (unnecessarily, if you need to return early then you can use this, however, I would wager it is possible to normalize the control flow for all cases and this would be better):

public void doStuff() {
  return;
}

The other approach is to use immutable objects and return an object that represents the next state, which is much safer:

doStuff().runStuff();

Or you could have run stuff that takes the next state as the parameter:

runStuff(doStuff());

Oh look, back to the beginning... But without the void return!

My two cents.

Stuart


On Wed, Feb 13, 2013 at 9:47 AM, Ged Byrne <[address removed]> wrote:
Hi Jon,

Satire aside, the JSR should be for the "result self pattern".

By default void methods should return self, so that they can be used in method chains as part of a fluent interface.



Regards, 


Ged



On 12 February[masked]:14, 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]





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Ged Byrne ([address removed]) from LJC - London Java Community.
To learn more about Ged Byrne, visit his/her member profile

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

  • 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