Looks like a good idea to me. What about aliases, though?
Should we provide a way to let them public by default while services will be private?

service_defaults:public:['aliases']# aliases are public whereas services are privateservice_defaults:public:true# default: aliases and services are public <=> ['aliases', 'services']service_defaults:public:false# aliases and services are private <=> []

(It'll need a special treatment for theservice_defaults.public key, but as we won't generalize theservice_defaults for every definition keys, I'd rather see this as aloader_config key than a "parent definition" one)

What about adding tags like this? I often find myself with a specific service definition file that contains a specific type of services. Think of a file for form types, they all have the same tag. It would be really nice if I could use this feature to automatically tag all definitions in that file by this implicit parent definition.

👍, you should add this new sectionhere or the ContainerBuilder will throw an exception.

Minor comment: could we please take some time to think about this proposal before merging it? This kind of changes can have a deep impact in how developers use Symfony. Personally I don't have an opinion about the idea yet ... but I don't like the implementation. It doesn't feel "natural" for Symfony.

As soon as it doesn't behaves blindly as a pseudo parent definition, but rather as a context/configuration exploitable by the loaders, it looks good to me. Hence, I don't really like theservice_defaults naming, but rather see something likeloader_config/context or whatever.

@javiereguiluz don't worry we have a process for that, this PR is no exception.

@ogizanagi I'm 👎 onloader_config because this is just leaking internal vocabulary that users don't necessarily know about.

PR completed for YamlLoader. If someone would like to work on XmlLoader, I'd happily accept a PR againstmy branch!

I like the idea!

What about using justdefaults as key?service_defaults is a bit redundant withservice:

defaults:public:falseautowire:['_construct', 'set*']services:foo:class:Foo

The best looking config is:

services:defaults:public:falseautowire:['_construct', 'set*']'Foo\Bar':{}

But I'm not sure that it's ok to deprecate some services names likedefault for this example.

The best looking config is:

Really? The one above looks more intuitive to me...

defaults:#...services:#...

that is.

Looking at it like this looks good... then again; if parameters are involved (parameters: #...) it may work counter-intuitive.

Meaning eitherservice_defaults (:+1:), or indeedservice.defaults.

The root namespace is used for container extensions configuration, that means there is a potential for collision with an existing bundle that uses this "defaults" name.
This leads to another reason pro-service_defaults: the defaults we're talking about are related toservices only.
If you have eg:

framework:#...services:#...defaults:#...

it's not intuitive at all thatdefaults applies only toservices.
That's why I agree with@dunglas thatdefaults insideservices is the best of the two proposals.
But is it worth the potential collision?

What about adding an underscore in this way?

services:_defaults:#...

Perhaps* works out as well? It looks nicer then_defaults at least :) and seems to fit the case perfectly?

I doubt* would be friendly to anyone not familiar with what it does.

Think you're right.. just typed it out to visualize in fact. It looks good (imo.) but indeed..you need to know it.

service._defaults 👍

What about using something that sounds more specific to yaml such as!defaults (as a key ofservices)?
It would also decrease the risk of conflicts.

!defaults must be quoted in yaml, not very friendly. And we already use_ prefixes for special keys in eg routing yaml.

@nicolas-grekas I was thinking about a tag returning something similar to the JavaScriptSymbol but yes custom tags aren't supported yet.
Currently, unknown tags are considered as part of the scalar (e.g.!defaults remains!defaults as it is not known) so it's possible to use them and we could later migrate to a better tags system, wdyt?

+1 forservices._defaults. Btw we should take this occasion to deprecate any service name starting by a_.

Just for inspiration from@nette, there is similar tool, that decorates specific classes/types of classes:

Seethis article - jump to "Decorator Extension to the Rescue" headline.

And this Tweet:https://twitter.com/VotrubaT/status/812802092356276224

I'm amazed, how similar these tools are :)

What about addfactory to list of _default options?
It can be useful to define doctrine repositories as service for example.

@grachevko How would that look like? From example I understand it's global setup for all services.

@TomasVotruba not a global. This PR add_default options which have affect only on file where it.
We can createsubscribers.yml and set_default.tags: [{ name: kernel.event_subscriber }] for all subscribers in this file without typing sametag to each.
Just the same we could createrepositories.yml and set_default.factory: ['@doctrine', 'getRepository'] without typing samefactory.

@grachevko Ah. That's a pity. I was looking forward to get rid of Console, EventSubscriber, FormType etc. tags.

I'll work on that Decorator feature then :)

👍

Thank you@nicolas-grekas.

The newinherit-tags option would have deserved its own line in the changelog imho, it's just great! Thanks