This message was deleted.

# language-proposals

[Slackbot]

This message was deleted.

[karelpeeters]

How would that work?

[louiscad]

@jossiwolf Why is your use case?

[jossiwolf]

@karelpeeters @louiscad Take the example of a class that should be a singleton (for example a ViewModelFactory)
Instead of having to use "hacks"like this: https://github.com/oldergod/android-architecture/blob/todo-mvi-rxjava-kotlin/app/src/main/java/com/example/android/architecture/blueprints/todoapp/util/SingletonHolderSingleArg.kt
https://github.com/oldergod/android-architecture/blob/todo-mvi-rxjava-kotlin/app/src/main/java/com/example/android/architecture/blueprints/todoapp/util/ToDoViewModelFactory.kt
In order to create an object with arguments, one has to make the constructor private and create a companion object
It's just sugar, but there could be a singleton keyword instead:
singleton class ViewModelFactory(dependency: Something)
Edit: Of course it could just be an object that accepts arguments

[Andreas Sinz]

and how would you initialize/retrieve the singleton?

[gildor]

imo it's anti pattern and shouldn't be used
Use proper DI instead

You never can be sure what is "dependency" in your case and can cause some hard to detect problems and memory leaks

[jossiwolf]

Initialization: Like a class (val factory = ViewModelFactory(...))
Two methods could be used for retrieval of the instance: One getInstance(parameters) and one getInstance throws NotInitializedException without any parameters
But I'm sure there could be other ways
I thought about that too @gildor, but I feel like DI shouldn't be the only way to do that as it can get quite complex and isn't exactly easy to get started with

[gildor]

So how user will use this, what should I choose getInstance with parameter or without? Your system now depends on initialization order

[gildor]

I don't see anything hard to implement this with DI or service locator

[gildor]

Especially with ViewModelFactory, not sure why do you need singleton at all, just create a new instance when you need it

[tschuchort]

I don't really see the use case for this. A singleton has global lifecycle and accessability so whatever dependencies you may need ought to have global lifecycle as well or you will leak. If you don't use DI, there is no reason (and practically no possibility) not to create the required dependencies in the ctor, since the dependencies, too, are available globally. Specifically in your example of the ViewModelProvider.Factory is there even a reason it has to be a singleton? Those things should have no mutable state so the instances are basically unary functions and instantiating corresponds to partial application of an n-ary function. So as long as the parameters are the same, the functions are equivalent. (What should happen if a parameterized singleton is instantiated with different arguments? You can either throw, ignore it or create a different one, in which case it's no longer a singleton).

IMO a true-to-its-name singleton is usually an anti-pattern anyway. As you realized, even if the dependencies are available globally it often still makes sense to inject them, for example to make the class testable. For the sake of our sanity the object's lifecycle should be bound to some other object (probably the DaggerAppComponent). Make lifecycle explicit and pull out that responsibility. The class has no god damn business knowing that it will be used as a singleton.

[jossiwolf]

I see, you've changed my mind. Many good arguments, thanks for the discussion!