@cosmastech how hard would it be to add the environment stuff in? I think it's pretty key to using this feature.

@cosmastech how hard would it be to add the environment stuff in? I think it's pretty key to using this feature.

Not hard, but tell me which you prefer:

Only allow the attribute once

#[Bind([
    ProductionTwChatService::class => ['staging', 'production'],
    StubTwChatService::class => ['local', 'testing'],
])]
interface ChatServiceInterface
{
    // ...
}

vs
Allow the attribute to be repeated

#[Bind(ProductionTwChatService::class, environments: ['staging', 'production'])]
#[Bind(StubTwChatService::class, environments: ['local', 'testing'])]
interface ChatServiceInterface
{
    // ...
}

Additionally:
What do we use to signify it's for all environments? environments: ['*']?

How do we signify the default fall-through if the environment is not specified?

Another question is: since the Container class doesn't have access to the environment, it would have to be handled by the Application class instead. What do we do in that case?

@cosmastech I think ['*'] is fine for all environments. If environments are defined but no matching environment is found, I would expect it to be as if the interface wasn't bound at all. I would maybe inject some environment resolver closure into the container via a setter like resolveEnvironmentUsing(fn). If that is not set then this feature would not work, but when using the framework we would set it for you.

I'll mark this as draft and get to to work on it. 🙇 Thanks @taylorotwell

Thanks - added enum support to environments 👍

Thanks - added enum support to environments 👍

Me--of all people--not thinking of adding enum support 😂

Let me know if you want me to take a tumble at adding docs for this.

Thanks @taylorotwell 👋 See you at Laracon!

I think this PR adds another way to do something that already works well, which could introduce unnecessary complexity. Supporting multiple ways to accomplish the same task can make the framework harder to refactor, maintain, and extend over time.

As Taylor Otwell has often emphasized:

To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.

If applicable, please consider releasing your code as a package so that the community can still take advantage of your contributions!"

I think we need to revert this one.