What's the point?

>You can do lazy initialization without singleton.
Example?

Singleton is only useful if there are other methods as well. It wouldn't make sense to only have an init function.
>If you honestly can't see the value of loading static variables lazily
You don't need singleton to load variables statically. Singleton just means you bake that into the class.
>you might just be the bad programmer that you are talking about and your programs will probably have issues with long startup times at some point.
Interesting that you assume the only two options are lazy initialization versus initializing everything at startup. You need to broaden your horizons a bit.
And finally, I must reiterate I am not even against lazy initialization in general (although I prefer not to use it myself). What I am against is the creations of classes which can only be lazy initialized. It's not a modular design. Classes shouldn't initialize and manage their own instances. It violates single responsibility.

Create a static object in function scope and return a reference to it from the function.
We're really at the point that singleton-ites are so deep into their pattern they can't see how basic things could be done outside of it?

>2022
>still not using dependency injection
ngmi

so dont

Retard proofing because globals are icky.

guessing you dont write tests either because you just dont make mistakes ?

Accidentally creating an instance is a very strange mistake to make, though. And you can also make your class not copyable, which eliminates the only real risk of doing it.
The biggest issue with singleton is it locks you into your design. Someday you will realize you actually need two of the object, or you need to initialize it in a certain way. In either of those cases you will get very stuck. The singleton api will be deeply embedded, and unpredictable because of the global accessibility. It's a maintenance nightmare.
I've worked at a company where people called the singleton access function just to initialize the objects, thereby overriding the lazy initialization. Even then they had trouble controlling initialization as singletons would internally initialize other sinerons during their initialization.

>Create a static object in function scope and return a reference to it from the function.
So in Java, something like this:
public class C {
private static final C INSTANCE = new C();
public static C getInstance() {
return INSTANCE;
}
}

Because that's just a singleton.

>You need to broaden your horizons a bit.
You either initialise something before you need it, or when you need it.
The only other option I can imagine is initialising it after you need it, which is not very useful.
>Singleton just means you bake that into the class.
This is only for cases where it only makes sense for there to be one of them.
It bakes it into the class in the same way that having a global variable bakes it into the variable, because a singleton is just a collection of global variables.
A singleton with only one attribute is literally the same thing as a global variable; there is no difference.

The risk isn't creating an instance. It's assigning the instance you just created to the global variable for the singleton.
Singleton solves this by making the global variable private to the singleton class.
>The biggest issue with singleton is it locks you into your design.
It doesn't do this. You can just factor all the fields out into another class, instance that class in the singleton (redirecting the singleton's methods to the new class), and then instance the other class as many times as you like.
No API change and the problem is solved.
Unless your issue is just having any global state, in which case, yes that can be a problem.

Honestly, I'm getting Poe's law. I can't tell if you're trolling or not because singleton-ites really are this stupid in general.

>Because that's just a singleton.
It's a singleton because the class is creating its own instance.
public class C {
public static B getInstance() {
static B instance = new B();
return instance;
}
}

Now do you understand the difference between singleton and general lazy initialization? Or is it still confusing for you?

>You either initialise something before you need it, or when you need it

I am not generally against lazy initialization as I have said in like 3 comments here so let's just drop it. But I do think you overemphasize the importance of the choice.

>This is only for cases where it only makes sense for there to be one of them.
Which is basically never.
>It bakes it into the class in the same way that having a global variable bakes it into the variable
Yes. See the difference between a CLASS and a VARIABLE? THAT'S THE WHOLE POINT, DUDE.

The entire issue with singleton is that prevents you from reusing a class because you've decided when you wrote it there should only be one. The issue is that often you eventually need more than one and in that case you're fucked.

>because a singleton is just a collection of global variables
Yeah, and I think it's been known for a while that global variables are not a good thing.

>A singleton with only one attribute is literally the same thing as a global variable; there is no difference.
Well, besides more boilerplate? Just use a global variable, that's what variables are for.

You are basically making a class into a variable with only drawbacks and no upsides. The whole point of classes that they can be reused (hence - a class of instances).

> It's assigning the instance you just created to the global variable for the singleton.

You mean the issue is modifying the singleton? Make it a constant?

>It doesn't do this. You can just factor all the fields out into another class, instance that class in the singleton (redirecting the singleton's methods to the new class), and then instance the other class as many times as you like.
lol, so the way to get around it is to remove it and use a bunch of boilerplate to maintain your singleton api? Really convincing.
Why not just start with the other class instead of starting with the singleton? Which by the way - is what I've been suggesting all along.

>It doesn't do this.
I forget to mention. All your call sites will be expecting singleton. So they are all locked into that api. Your solution just explains how to maintain the singleton api, but there's more to it than that.