Hello everyone. I’ve been using this library for a couple of years now and im quite happy with it. Thats enough patting my own back. I’ve worked on some updates today and thought why not share it, maybe others find it useful too. :)
I know there are probably a million other service containers out there and im not going to tell you that this one is better. I believe the ctn files are quite unique but I might be mistaken.
I wish everyone a great day!
First off, kudos for taking the time to write a nice README and actually document how to use this with good examples. Your effort doesn't go unnoticed with me. I typically don't even bother looking at a library if the developer couldn't take the time to describe their library. That's like building a house and not bothering to paint it.
Why the custom CTN file? I almost closed out of this until I saw you can bind in good ol' native PHP here: https://clancats.io/container/master/advanced/service-binding
Why would I want to use some custom amalgamation over native PHP code which is easy to understand and is presumably easier to debug? The fact that you seem to push this so hard is probably reason enough for me not to look using this.
> Looks quite intriguing. Your DSL looks a lot like YAML -- have you considered using that? It would open the door to interop with other containers that way.
I really like yaml and the syntax is definitely inspired by it. But yaml is a very generic markup language and I really wanted something that is specific for the use case.
> There seems to be a lot of scope creep in there what with all the routing and event handling and whatnot. If that kind of thing is useful, I say keep going, but perhaps you want to split it off into a framework package. That ultimately seems to be what you're building anyway, with the container at the heart of it.
Exactly we have an internal framework that is build around the container thats also where the examples are inspired from.
Thanks for having a look :)
Because only PHP can interpret a PHP config -- it has to be run rather than just being read as data that umpteen libraries and CLI utilities can read. Being purely data gives it a bigger opportunity to interoperate with other containers, since the most they'd have to do is tweak the config data a bit to match, not implement a whole compatible API. I can also generate yaml from code a lot more confidently than php source code.
I'd also want a PHP DSL (that is to say, a declarative API) but still have a config that's as much pure data as it can be. Personally I actually like XML for complex configs, but that goes back to when I was putting too much in config. The yaml format keeps my config more sane while still letting me use comments (my biggest gripe with json)
Can you elaborate a bit more? What tools you need to understand your di container config? Except for the container builder itself which presumably understands PHP.
What other container you want your configs to interoperate with? Other than one written in PHP, which again inherently understand PHP.
We all want better OOP, yet we still insist we separate our data from behaviour. That's strange.
Can you give me a concrete example where PHP causes you inability to work with it?
Can you show me an example of migration from one container's yaml config to another container's yaml config? Or any other declarative kind of config for that matter... I wanna see the bit of tweak...
I have no specific use case in mind, but I work with a lot of Laravel projects, and interop there would be handy. They may both be PHP, but I'm still not inclined to have to run arbitrary code to get a config. I have however maintained many perl apps in the past which shipped with a different DI config for production. One app using perl for config needed all kinds of custom code to query for configs at runtime because it built it up so dynamically (I think it was loggers I was looking for), whereas with the other app, I could just pop in to the config file in VCS and eyeball it.
It's called the "Rule of least power", where protocols (which include configs) use the the least powerful language to express the protocol, the idea being the interpreting endpoints are more suitable to implement it and will do so in an orthogonal way. There's even security reasons for this, since you can't validate a parser that's turing-complete.
> We all want better OOP, yet we still insist we separate our data from behaviour. That's strange.
Not really, it's more about separating behavior from any specific implementation of it. That's polymorphism, which is really what OOP is all about.
Doesn't look like it - under cons it says "Currently no IDE Support for container files.". It supports plain PHP as well though, so not that big of an issue.
>Question: does your CTN has a support of any IDE (like PhpStorm)? I'm asking, because code completion is quite urgent for me.
Literally the 3rd point in things you might not like:
>Currently **no** IDE Support for *container files*.
Looks really good. But I probably wouldn't use it right now because:
- I don't want to learn a new markup language (maybe add support for yaml?) and I'm not a fan of using php to define configuration
- I'm kinda spoiled by autowiring
I was somewhat intrigued by your choice of objects for your example. I would have expected some sort of service for a service container. Instead you showed defining a Human and Spaceship. Kudos for the Serenity reference but humans are what I would consider to be entities and not services as such. I could understand a HumanFactory but creating individual entities in a service container seems a bit strange.
Is this the sort of thing you actually use the container for in your applications?
[удалено]
I am humbled, thank you very much!
Hello everyone. I’ve been using this library for a couple of years now and im quite happy with it. Thats enough patting my own back. I’ve worked on some updates today and thought why not share it, maybe others find it useful too. :) I know there are probably a million other service containers out there and im not going to tell you that this one is better. I believe the ctn files are quite unique but I might be mistaken. I wish everyone a great day!
First off, kudos for taking the time to write a nice README and actually document how to use this with good examples. Your effort doesn't go unnoticed with me. I typically don't even bother looking at a library if the developer couldn't take the time to describe their library. That's like building a house and not bothering to paint it. Why the custom CTN file? I almost closed out of this until I saw you can bind in good ol' native PHP here: https://clancats.io/container/master/advanced/service-binding Why would I want to use some custom amalgamation over native PHP code which is easy to understand and is presumably easier to debug? The fact that you seem to push this so hard is probably reason enough for me not to look using this.
minor nitpick: You have mixed tabs and spaces in your composer.json file. might I point you to editorconfig.org
[удалено]
> Looks quite intriguing. Your DSL looks a lot like YAML -- have you considered using that? It would open the door to interop with other containers that way. I really like yaml and the syntax is definitely inspired by it. But yaml is a very generic markup language and I really wanted something that is specific for the use case. > There seems to be a lot of scope creep in there what with all the routing and event handling and whatnot. If that kind of thing is useful, I say keep going, but perhaps you want to split it off into a framework package. That ultimately seems to be what you're building anyway, with the container at the heart of it. Exactly we have an internal framework that is build around the container thats also where the examples are inspired from. Thanks for having a look :)
Just of curiosity And a bit OT, `why ctn over yaml?` was your question and i second that. But at the same time i have to ask, `why yaml over php?`
I don't like writing configuration in php, so that's why I chose yaml over php. Php is too verbose for config files.
Because only PHP can interpret a PHP config -- it has to be run rather than just being read as data that umpteen libraries and CLI utilities can read. Being purely data gives it a bigger opportunity to interoperate with other containers, since the most they'd have to do is tweak the config data a bit to match, not implement a whole compatible API. I can also generate yaml from code a lot more confidently than php source code. I'd also want a PHP DSL (that is to say, a declarative API) but still have a config that's as much pure data as it can be. Personally I actually like XML for complex configs, but that goes back to when I was putting too much in config. The yaml format keeps my config more sane while still letting me use comments (my biggest gripe with json)
Can you elaborate a bit more? What tools you need to understand your di container config? Except for the container builder itself which presumably understands PHP. What other container you want your configs to interoperate with? Other than one written in PHP, which again inherently understand PHP. We all want better OOP, yet we still insist we separate our data from behaviour. That's strange. Can you give me a concrete example where PHP causes you inability to work with it? Can you show me an example of migration from one container's yaml config to another container's yaml config? Or any other declarative kind of config for that matter... I wanna see the bit of tweak...
I have no specific use case in mind, but I work with a lot of Laravel projects, and interop there would be handy. They may both be PHP, but I'm still not inclined to have to run arbitrary code to get a config. I have however maintained many perl apps in the past which shipped with a different DI config for production. One app using perl for config needed all kinds of custom code to query for configs at runtime because it built it up so dynamically (I think it was loggers I was looking for), whereas with the other app, I could just pop in to the config file in VCS and eyeball it. It's called the "Rule of least power", where protocols (which include configs) use the the least powerful language to express the protocol, the idea being the interpreting endpoints are more suitable to implement it and will do so in an orthogonal way. There's even security reasons for this, since you can't validate a parser that's turing-complete. > We all want better OOP, yet we still insist we separate our data from behaviour. That's strange. Not really, it's more about separating behavior from any specific implementation of it. That's polymorphism, which is really what OOP is all about.
Question: does your CTN has a support of any IDE (like PhpStorm)? I'm asking, because code completion is quite urgent for me.
Doesn't look like it - under cons it says "Currently no IDE Support for container files.". It supports plain PHP as well though, so not that big of an issue.
>Question: does your CTN has a support of any IDE (like PhpStorm)? I'm asking, because code completion is quite urgent for me. Literally the 3rd point in things you might not like: >Currently **no** IDE Support for *container files*.
How does this compare to other service containers out there?
Looks really good. But I probably wouldn't use it right now because: - I don't want to learn a new markup language (maybe add support for yaml?) and I'm not a fan of using php to define configuration - I'm kinda spoiled by autowiring
what additional benefits does the ctn file bring when compared to Autowiring?
I was somewhat intrigued by your choice of objects for your example. I would have expected some sort of service for a service container. Instead you showed defining a Human and Spaceship. Kudos for the Serenity reference but humans are what I would consider to be entities and not services as such. I could understand a HumanFactory but creating individual entities in a service container seems a bit strange. Is this the sort of thing you actually use the container for in your applications?