Extend binding API to create aliases
See original GitHub issuewe want to have something like
bind(IFoo1.class).to(Foo.class);
bind(IFoo2.class).to(Foo.class);
@Singleton class Foo {}
But the issue is that doing so would create to 2 Foo instances, kept in internal providers for the keys Foo1 and Foo2.
It would be nice to have something like an alias
bind(IFoo2.class).asAliasOf(IFoo1.class);
so that the keys Foo1 and Foo2 would point to the same internal provider.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:2
- Comments:5 (1 by maintainers)
Top Results From Across the Web
Data-binding - Coherent Prysm Exporter Documentation
Data-binding aliases exist only in the Prysm Animate Plugin and are used to generate data-binding expressions. They do not have a representation in...
Read more >Creating multiple aliases for the same QueryDSL path in ...
I am trying to extend the basic equality testing built into the default repository implementation, so that I can perform other query operations ......
Read more >Aliases API | Elasticsearch Guide [8.5] | Elastic
Aliases API edit. Performs one or more alias actions in a single atomic operation.
Read more >Extending the Kubernetes API with Custom Resources
To create custom objects, you must first create a custom resource definition (CRD). Only cluster admins can create CRDs. Procedure. To create a...
Read more >Routing traffic to an Amazon API Gateway API by using your ...
An API Gateway API that has a custom domain name, such as api.example.com that matches the name of the Route 53 record that...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
In my opinion the expected behavior for this code is to create a single instance of Foo without any aliases. Otherwise what does
@Singleton
mean here?Yes, seems like a viable option!