This PR was merged into the 3.4 branch.
Discussion
----------
[DI] Case sensitive parameter names
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | #23809
| License | MIT
| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->
@GuilhemN took your patch.. but i use the same deprecation messages as for case sensitive service id's, i found it more clear. Also comparing to $origName to keep the diff smaller
Commits
-------
8a1d16839e [DI] Case sensitive parameter names
This PR was squashed before being merged into the 3.4 branch (closes#22187).
Discussion
----------
[DependencyInjection] Support local binding
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes <!-- don't forget updating src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | no <!-- don't forget updating UPGRADE-*.md files -->
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/issues/22167, #23718
| License | MIT
| Doc PR |
> A great idea came out on Slack about local bindings.
> We could allow injecting services based on type hints on a per service/file basis:
> ```yml
> services:
> _defaults:
> bind:
> BarInterface: '@usual_bar'
>
> Foo:
> bind:
> BarInterface: '@alternative_bar'
> $quz: 'quzvalue'
> ```
>
> This way, `@usual_bar` will be injected in any parameter type hinted as `BarInterface` (in a constructor or a method signature), but only for this service/file.
> Note that bindings could be unused, giving a better solution than https://github.com/symfony/symfony/pull/22152 to https://github.com/symfony/symfony/pull/21711.
>
> As named parameters are usable in arguments, bindings could be usable in arguments too:
> ```yml
> services:
> Foo:
> arguments:
> BarInterface: '@bar'
> ```
~Named parameters aren't supported yet.~
Edit:
> Note that bindings could be unused
Current behavior is throwing an exception when a binding is not used at all, in no services of a file if it was inherited from `_defaults` or in no services created from a prototype.
It will pass if the bindings are all used in at least one service.
Commits
-------
81f2652 [DependencyInjection] Support local binding
This PR was squashed before being merged into the 3.4 branch (closes#22913).
Discussion
----------
[Yaml] Deprecate tags using colon
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no <!-- don't forget updating src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
Using a colon in a tag doesn't look like yaml and causes trouble (see https://github.com/symfony/symfony/pull/22878), so I propose to just deprecate these tags in favor of more consistent tags.
```yml
- !php/const:PHP_INT_MAX
- !php/object:O:30:"Symfony\Component\Yaml\Tests\A":1:{s:1:"a";s:3:"foo";}
```
would become
```yml
- !php/const PHP_INT_MAX
- !php/object O:30:"Symfony\Component\Yaml\Tests\A":1:{s:1:"a";s:3:"foo";}
```
Commits
-------
9815af3 [Yaml] Deprecate tags using colon
* 3.3:
[DI] use assertStringEqualsFile when possible
[VarDumper] Adapt to php 7.2 changes
[DI] Fix using private services in expressions
[Form][TwigBridge] Don't render _method in form_rest() for a child form
[Form] Static call TimezoneType::getTimezones
Removed references for non existent validator constraints
Suggest using quotes instead of Yaml::PARSE_KEYS_AS_STRINGS
[DI] Fix test
[Cache] Handle unserialization failures for Memcached
Remove unused prop + added @deprecated
Remove unused mocks/vars
[DoctrineBridge][PropertyInfo] Added support for Doctrine Embeddables
[Validator] Fix IbanValidator for ukrainian IBANs
Router: allow HEAD method to be defined first
[WebProfilerBundle] Display trace and context in the logger profiler
Fixing a bug where if a core class was autowired, autowiring tried to autowire optional args as if they were required
* 3.2:
[DI] use assertStringEqualsFile when possible
[VarDumper] Adapt to php 7.2 changes
[DI] Fix using private services in expressions
[Form][TwigBridge] Don't render _method in form_rest() for a child form
[Form] Static call TimezoneType::getTimezones
Removed references for non existent validator constraints
Remove unused mocks/vars
[DoctrineBridge][PropertyInfo] Added support for Doctrine Embeddables
[Validator] Fix IbanValidator for ukrainian IBANs
* 3.3:
[Profiler] Fix data collector getCasters() call
remove symfony/process suggestion
[DI] Remove unused dynamic property
[Process] Fixed issue between process builder and exec
non-conflicting anonymous service ids across files
* 3.3:
Fix optional cache warmers are always instantiated whereas they should be lazy-loaded
add some \ on PHP_VERSION_ID for 2.8
[Di] Remove closure-proxy arguments
[PropertyInfo][DoctrineBridge] The bigint Doctrine's type must be converted to string
This PR was merged into the 3.4 branch.
Discussion
----------
[DI] Deprecate XML services without ID
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no, confusing though
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->
On slack someone had a issue with class named services;
> So, probably should have done this sooner, I stepped through with a debugger and it looks like \Symfony\Component\DependencyInjection\Loader\XmlFileLoader::processAnonymousServices assigns a sha256 to services that don't have any IDs
> When my manually wired service is registered, it has an ID that looks like 1_344b468f6069ffe8c32092409d99c59abc218f41071ce4c4230c198876129bc0, so it doesn't override the auto-loaded one
> I swear I read that IDs default to the class name now...
The fix was easy; doing `<service id="ClassName"/>` instead of `<service class="ClassName"/>`. However the thing is... i made the exact same mistake trying to reproduce 😅
I think given the recent developments (dropping type based autowiring and class named services) it makes sense to force XML service to specify an ID attribute (the top level ones). This would be consistent with YAML and PHP as well.
Fixing deprecations is also easy, just change `class` attribute to `id` like i've done for the frameworkbundle in this PR.
Any thoughts?
Commits
-------
b8c68da010 [DI] Deprecate XML services without ID
* 3.2:
[DI] Avoid private call to Container::has()
Fixing missing abstract attribute in XmlDumper
[Form] Remove DateTimeToStringTransformer $parseUsingPipe option
Fix file perms
Fixed filename in help text for update-data.php
* 2.8:
Fixing missing abstract attribute in XmlDumper
[Form] Remove DateTimeToStringTransformer $parseUsingPipe option
Fix file perms
Fixed filename in help text for update-data.php
* 2.7:
Fixing missing abstract attribute in XmlDumper
[Form] Remove DateTimeToStringTransformer $parseUsingPipe option
Fix file perms
Fixed filename in help text for update-data.php
This PR was merged into the 3.3-dev branch.
Discussion
----------
Fixing a bug where abstract classes were wired with the prototype loader
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | none
| License | MIT
| Doc PR | n/a
The prototype/PSR-4 loader currently tries to wire abstract classes. The problem is if, for example, you have, for example:
```php
abstract class BaseCommand extends Command
{
}
```
If this is registered as a service, and you have `autoconfigure`, then the console `Application` will try to use this a command.
Was there some reason abstract classes were originally allowed to be registered as services with the PSR4/prototype loader? I don't know if there is a real use-case for registering abstract classes. If you wanted to use that service as a parent service... then you'll probably be configuring it yourself anyways. We could also fix this by changing all tags compiler passes to skip classes that are abstract... *if* there is a use-case for Abstract classes being auto-registered.
Cheers!
Commits
-------
5326bab10a Fixing a bug where abstract classes were wired
* 3.2:
[Console] Do not duplicate Helper::strlen() code
[FrameworkBundle] Adding the extension XML
[Form] Minor: Fix comment in ChoiceType
[FrameworkBundle] AbstractConfigCommand: do not try registering bundles twice
fixed CS
fixed CS
[DI] Fix PhpDumper blank lines around namespace
fixed CS
[Workflow] fix use directives
[Workflow] Move twig extension registration to twig bundle
Filesystem: annotate the one network test with a "network" group.
[DependencyInjection] Don't store default deprecation template in every service definition instance
* 2.8:
fixed CS
[DI] Fix PhpDumper blank lines around namespace
fixed CS
Filesystem: annotate the one network test with a "network" group.
[DependencyInjection] Don't store default deprecation template in every service definition instance
Now that inherit_tags has been removed, 3.3 has the same functionality as 3.2: tags
are *never* cascaded from parent to child (but you tags do inherit from defaults
to a service and instanceof to a service).
