• NULLPTR (unregistered)

    this=nullptr; this.DoSomething();

  • P (unregistered)

    The one who wrote this probably doesn't know what is polymorphism (and that you can cast/assign to a variable typed as its parent class directly), hence used this as a dumb way to do the same thing. My guess.

  • Mike (unregistered)

    Looks like that was initially a singleton, then was deemed unnecessary. They started like this, and then decided to throw away the static initializer. Been there, done that...

    private static Goofy me = new Goofy (); private Goofy () {}

     public static Goofy getInstance(){
    return me;
}
  • (nodebb)

    This...is this.

  • ZPedro (unregistered)

    ...And given that Java bytecode is stack-based, in all likelihood this gets compiled to:

    Package:Task:getInstance: return;

  • Simon Clarkstone (unregistered)

    The only situation I can think of where this might be useful is if that method is

    • an override of something,
    • overridden by something, or

    • ends up being used as the implementation of an interface method by the class being extended by another class that also implements that interface, e.g.

      interface A { void m(); }
class B { public void m() { ... } }
class C extends B implements A { ... } // uses implementation of m() from B to implement interface A, even though B isn't declared as extending A.
  • scriptninja (github)

    Now I kinda want a football bat.

  • (nodebb)

    What are the odds (astronomically high!) that the people using this function never looked at it and actually thought they were creating new tasks...

  • (nodebb)

    This method answers questions like "what is this?" and "what the f*** is this?"

  • Wim ten Brink (github)

    To be honest, it's not a bad design patterns as this is actually used quite regularly. I even used it in my most recent project. The only difference is that I tend to do a bit more before I return 'this'. It is a perfectly fine use for method chaining, which allows you to chain function calls with a single statement. E.b. myData.Sort().Export(Filename).Filter(Condition).etc()... The MyData class would thus implement the sort method to sort it's content and then return itself so the second function can now export the content from the same object. Which then gets filtered in the third method and more work will be done after that. Sure, you could put all of this functionality inside just another function but that makes the code more complex as you'd either end up with one big function doing everything or a big function calling several other functions. This design pattern keeps the functions a lot simpler and with proper code formatting it should still be very readable. Seems to me that someone prepared it for this kind of method chaining and then someone else removed the code but kept the 'return'...

  • I can be a robot if you want me to be (unregistered)

    Probably getInstance had more code and did something, then the need changed and the code was removed but everything that used it left in place.

  • Appalled (unregistered) in reply to I can be a robot if you want me to be

    Of course that's what it was. Removed code with stub retained for easy future reinstatement.

  • Developer Dude (unregistered) in reply to P

    Inheritance of not, it is still just as useless, and there is no indicator that this was about the method returning an ancestor class or an interface - that is just an assumption based on lack of more code.

  • James (unregistered) in reply to Mr. TA

    answers or raises?

  • sizer99 (google)

    In addition to the 'this was a singleton' theories, which are reasonable, this could be a guy who does singletons all the time because he loves global variables (I know these monkeys), and by god he's going to treat this as a singleton too.

  • (nodebb)

    Could only be made better if it was:

    public Task getInstance() { return new Object(this); }

  • (nodebb)

    Count me amongst those who think it used to do something useful.

  • ooOOooGa (unregistered) in reply to scriptninja

    How about a football racquet?

    Not only is it not needed for the game, it probably wouldn't work if you tried it.

  • MiserableOldGit (unregistered)

    I'd go with it being a remnant of something removed but not totally scrubbed. Either that or scruffy way of debugging some weird problem that got left in in case the problem came up again.

  • NULLPTR (unregistered) in reply to Bananafish

    Or public Task getSomething(){ new Task(this);} public void setSomething(Task task){/code here/}. Then serialize that type with SnakeYaml. BOOM stackoverflow. (check java.awt.Point, it contains this trap which caused me to waste a few hours debugging it since stacktraces didn't show it)

  • Guest (unregistered)

    Yes, yes, we know about this, but what about that?

  • Paul Neumann (unregistered) in reply to Wim ten Brink

    So, it's basically a fluent null operator

  • FristName LastName (unregistered) in reply to Guest

    Ah, but that's another story . . .

Leave a comment on “Do You Need this”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article