Can XyzAware-interfaces and setter/wither-dependencies die already? It’s a horrible practice.
Your service dependencies should be fully set after the constructor call.
Also, using the container directly is a horrible practice, too.
Constructor-Injection, iterable-injection by tags/interfaces, zero exposure of dependencies.
There’s a lot to improve.
How would you do it? Looking forward to learn something here.
I agree with you on all points, but I think the use of the container is just oversimplified examples. It’s the minimal code needed to bootstrap and use the container, when in real life you’d have the container injecting the dependencies. Though I’m not sure why the container is brought into it at all, since it’s meant as a testing library, and unit tests should use manually constructed dependencies, not DI.
The empty tag interface is so that you don’t need to manually set up the injection in services.yaml. It certainly beats a base class. Not sure why it wasn’t just rolled into GeneratorAware though, maybe so it doesn’t dictate the exact mechanism as an instance method.
I’d still call it a grey area. It also doesn’t help that the class he’s using looks like a domain Entity. Me, I don’t think I’d bother with all the fancy frippery, I’d rather just use it as a generator of realistic examples for docs. Of course my usual test data tends to look like “TEST_XYZ_FOO” so I can pick it out easier, but different strokes I guess…
!remindme 3 days
Until then this is the fork that I’ve been using, it’s easy to remember too:
https://github.com/FakerPHP/Faker
Edit: Never noticed the updated docs, much better than the previous ones:
https://fakerphp.github.io (edit: lol)
Also check out this:
https://github.com/FakerPHP/Faker
Thanks for the compliment on the docs 🙂
I have nothing to add but I’d love to see this package renewed
Nyholm is awesome. This spec has the thoroughness and tightness I expect from him.
I would miss some of the “just use it” ease of 1.0 but I imagine some of that would come with one’s own wrapper of typical extensions & locales.
!remindme 3 days
The maintainer didn’t have time for it anymore. There was no other option.
the maintainer himself said he didn’t want to develop it further nor did he want to accept others contribution and asked the community to fork it
I had my own popular open source project hostily forked in the early 2000s and it was devastating to me.
That’s literally one of open sources biggest selling points
Let me start by saying thank you to François for maintaining the library for so long. However, he made it very clear that he wouldn’t be updating the library anymore. That’s when we decided to fork it, add multiple people as maintainers to both Github and Packagist to avoid bottlenecks in the future, and continue development. This continued development already brought us PHP 8 support, multiple new providers, and way better documentation.
It was not, like you stated, a hostile takeover.
I had my own popular open source project hostily forked in the early 2000s and it was devastating to me.
What?
Don’t do open source if you don’t want forks? Easy as that.
hostily forked
What a ridiculous concept.
There are a million reasons to fork a project, all of which contribute to the open source community – for better or worse – and yours or anybody’s feelings about it are completely meaningless.
Members
Online