2
Tayo
17d

Pro tip:

Don't make stateful singletons. Just spent an entire fucking morning debugging because one of those fuckers was trying to use prod, and not the demo environment.

Comments
  • 5
    Pro tip:
    don't use singletons at all. :)
  • 0
    Pro tip:

    Yeah ik I'm a retard
  • 3
    I disagree. It's just yet another design pattern that has benefits as well as trade-offs.

    I used singleton in a cross-compatible terminal library which would break when you'd create multiple instances of the Terminal class.

    "Why," do you ask? "Couldn't you design a better API and don't use singleton?" There could be a way to do it without singleton, tough I doubt it's a better solution.

    You see, the terminal has a state (e.g. modes) and is being treated the same as a singleton (you can't execute an application and expect the error log to appear in different terminal).

    For this reason, I'm kinda forced to use singleton too. Imagine you'd create an instance every time you want to play an animation and you've multiple threads doing the same. It's guaranteed to break (switching to the normal mode after running out of scope while another animation plays, various frame buffers eliminating each other every tick, etc).
  • 0
    @PublicByte fair enough, but I tried to be smart and turn RPC API interfaces into singletons. At first it seemed like a good idea to reduce CPU usage, but the difference turned out to be negligible and only cause more issues than its worth.

    So there's that
  • 0
    var noob = this.Rant.User.name;
    Pro tip:
    Explain to the noob what a Singleton is.
  • 0
    @Ranchu ok boomer
  • 0
    @351483773 pro tip : They never make sense. It's a bad practice (**looks at current code with at least 10 different singletons in project**)
  • 3
    When you realize that most (if not all) software objects are a way to manage global state (albeit in a controlled manner), you realize singletons are just one specific way to manage this state. Often singletons are used to manage IO interfaces that can have only one instance. Also, if you want to have multiple singletons later, you can turn the instance call into a mapped generator. This has been particularly useful for testing rigs. Though that didn't have IO involved.

    The most fun reason to use a singleton though, is to see noobs cry and moan about why they are evil.
  • 2
    @Demolishun singletons do have their uses yeah, I've used them a few times before. One example would be a config class.

    In my mind I had a cool application for them in another project, but it just didn't work out like I wanted due to messy state management. That's all.
  • 0
    pro-tip: there are platforms (for example Unity Engine) where singletons are literally the only way of persisting data/state between scenes (without having to do disk i/o), and i see nothing wrong with that.
  • 1
    Just piping in with: singletons are widely abused. Some state is unavoidably global (e.g. MPI session), but I've seen so much code use a singleton to represent something that is only contingently unique.

    And then you want to come along and extend the functionality, or mock something for testing, and that singleton bites you in the bum.
Add Comment