laravel/framework — pull request #6346 by franzliedke (2014-11-07 00:59:00+00:00)
Title: [5.0] Aliases in service providers

This gets rid of the `registerCoreContainerAliases()` method in the base application class.

The benefits:
- aliases are defined where the bindings are registered (easier to maintain),
- service providers can more easily be re-used in other projects that do not use the application class (especially now since `illuminate/foundation` is gone)

While I was at it, I removed the aliases for the bindings called `paginator` and `artisan`. I could trace the removal of the former, not quite sure about the latter. Please confirm, @taylorotwell.

#### Question

I'm a little bit unsure about the alias(es) for the `request` binding. As the instance is bound to the container once in the HTTP kernel, once in a console bootstrapper, I added them in both places. Any better idea?

#### Deferred providers

I assume this will cause problems with deferred providers, which are not yet solved. Until now, when somebody wants to resolve a constructor argument typehinted with e.g. `Illuminate\Contracts\Redis\Database`, this would be recognized as an alias for `redis`. The application would then notice that this is provided by a deferred service provider and subsequently load it. Now, the aliases will not be registered until the service provider is actually loaded. Therefore, typehinting interfaces or classes that are registered in deferred providers would not work.

This affects the following service providers:
- `Illuminate\Auth\Passwords\PasswordResetServiceProvider`
- `Illuminate\Cache\CacheServiceProvider`
- `Illuminate\Hashing\HashServiceProvider`
- `Illuminate\Mail\MailServiceProvider`
- `Illuminate\Queue\QueueServiceProvider`
- `Illuminate\Redis\RedisServiceProvider`
- `Illuminate\Translation\TranslationServiceProvider`

I see the following ways around this:
1. When building the service provider manifest, run the `register()` methods and take note of all registered aliases. This would work for all aliases, except the one for the Blade compiler, as that will only be registered once the view factory is actually resolved. (We can change that? Or do we even need that alias?)
2. Add the aliases to the `provides()` array. This is duplication that I would like to avoid.
3. Add some kind of wrapper for alias generation in service providers. Either another method or a property, that would automatically be combined with the results from `provides()` when generating the manifest.