Autowiring & Public/Private Services

Yo Adam Hazda!

Sorry for my slow reply :). I love questions! And these are good ones!

> why is it that .xml format is the best practise for service definitions?

A LONG time ago, we made this decision on the core team: YAML for applications as a best practice, XML for shareable stuff. Back then, there were a few edge-case things you could do in XML that you could not do in YAML, but I'm 99% sure that is not the case anymore. So.... it really doesn't matter :). The *one* edge thing I can think of is this: if you use YAML, then your bundle is dependent on the YAML component. And, in theory, some apps could be built without using YAML, and they may not love that your bundle requires it to be installed. Pretty minor reason, but there ya go.

And PHP? Yea, you could totally just use PHP! I think most people don't think that the PHP service definition is *as* readable, but obviously, there is zero technical disadvantage to it.

> The second question is about service IDs. Provided that our classes depend on abstractions, not other concrete classes AAAND provided that we do not use autowiring, instead we are in full control of what is really being injected into our classes (inside our Bundle), why do we need to use snake_case_ids? Wouldn't it be nice to use Interface names instead?

This is a pretty new conversation that we're having. Snake case id's were always used *everywhere* (apps & bundles) until Symfony 3.3, when we started using class ids for applications. It's an interesting question to use interface names as service id's. I can make a pretty good case for not using the *class* names as the service ids, but interface names is definitely more interesting :). In practice, I think there's not a big problem. But, I can see *potential* issues: (A) if you have services that aren't meant to be used by end-users, then by using the interface as the id, you've enabled that service to be autowired (and it will be displayed in debug:autowiring). You definitely don't want that, so this kills the idea of interface ids for at least your "internal" services. (B) More minor, but it's possible that 2 different bundles will want to register a service for some external library (e.g. maybe a bundle wants to register their own event dispatcher to be used only by the bundle). Using the snake case allows you to give the service id a unique name to avoid clashing.

I hope these answers are satisfying. If you've got more, let me know!

Cheers!

Hey Ryan, thanks for your Response! Your first answer makes complete sense! But I am still I little bit confused about the second topic. (B) I see your concernes on service name clashing. For the sake of service name uniqueness I suppose it would be just fine to use FQNs (of classes or interfaces) instead of some made up snake case names. I also suppose that every class is behind some kind of namespace that includes vendor name and bundle name that make it unique, which is the point of service id? Just a string of unique and referenceable characters carrying some hint about it's usage and vendor, I guess?. Now (A),.. I get your point, maybe I just can't imagine the real case. If a consumer of my bundle typehints some of his argument with my internal Interface I guess it's okay to have it autowired and injected inside his service. I can imagine though, that registering my internal service with some really general id like Psr\Log\LoggerInterface might invoke some unexpected behavior.
I just really seem to hate snake case IDs you know... 😀. Class names are like constants. You can't really screw it up, even without some fancy Symfony PHPStorm plugin handling snake case IDs.

Cheers!

Update:

I just realized that I didn't really take into consideration the part you said about *external library* and you're right. Maybe if I let's say,.. needed a different EventDispatcher, as you mentioned before, for my bundles internal workings then I have two possibilities I can think of: 1, I can completely reuse the class from Symfony, but I just need it to be assembled (compiled) differently, maybe with some different method calls (I need to make up some ID here) 2, I can either extend the class or decorate it, which would mean I want to add or modify some of the functionality, which would possibly lead to a new Interface I then use as an ID.
I would still probably go for the new Interface anyway 😀.

Hey Adam Hazda!

Great reply. So yea... you obviously understand the whole situation very well. There are just a FEW edge cases that makes using class/interface name service id's everywhere a problem... and so, we basically don't recommend them. But, those are for sure edge cases!

About the autowiring point (A) from above, another way to think about it is this: if my class registers 5 services, but only 1 is meant to be used by the end-user, by using snake-case (and only creating a class name / interface name alias for the 1 service), then when a user runs bin/console debug:autowiring, they will only see the 1 service there, not all 5. I think that's important: I want debug:autowiring to be as short as possible - showing the user only the important stuff :).

Anyways, great convo! I hadn't really ever thought through the repercussions of class/interface ids in reusable stuff before.

Cheers!

Hey,

Do you mean this file?

services:
    knpu_lorem_ipsum.knpu_ipsum:
        class: KnpU\LoremIpsumBundle\KnpUIpsum
        public: true
    
    KnpU\LoremIpsumBundle\KnpUIpsum:
        alias: 'knpu_lorem_ipsum.knpu_ipsum'
        public: false

Cheers!

Yes maybe You can provide us all xml files from the start of the course and from the end.

But this is also ok.

Thank you

Heh.. sorry but no :-)

As you can see, it's not difficult to do, and the main question is: Why do you need it?

Cheers!

Yes, I don't need files for this project, of course.

My idea was to share those files as an example, so we can use them for some other projects.

But it's fine this way too - thank you very much

Btw, these days, it's even more common to use PHP to define services in bundles, which is probably a bit easier than YAML ;). Here's an example: https://github.com/symfony/ux/blob/2.x/src/StimulusBundle/config/services.php - and it's loaded here - https://github.com/symfony/ux/blob/2.x/src/StimulusBundle/src/DependencyInjection/StimulusExtension.php#L32-L33

Cheers!

Hey Jude,

Thank you for your interest in SymfonyCasts tutorials! Could you explain what you mean about "simple bundle name"? Any examples to compare how it would be with different what would be easier?

Cheers!

Thanks Jeremy B.! We will add a note about this!

Hey Anton,

Just a friendly ping, the video file name was fixed already.

Cheers!

Hey Anton B.

Thanks for informing us. We will fix it soon :)

Cheers!

Hey Etienne L.!

Sorry for my late reply to such a good question! Let me start by clarifying one thing: in new bundles.... yes... probably you should have NO public services anymore. However, I'm not sure yet how if it's too soon to "force" this in the community. But, my instinct (even though I did something a bit different here) is yes, to make everything private for *new* bundles.

This means that, indeed, it's a good idea to keep public="false" for the snake-case service. About the alias, this SHOULD be public: it's *only* purpose is to provide autowiring (which doesn't require it to be public). Of course, IF you DID want to continue making one service public, I suppose you could make this be the alias... I hadn't really thought about it. But yea, why not? :)

Cheers!

Hey weaverryan

Thanks for the reply, yeah it makes sense !
I just wanted your opinion on that :)

Cheers !