driftphp
DriftPHP goes Symfony Flex
Since Symfony-Flex is the defacto standard for new projects since 4.something, I tried to adopt the structure with the DriftPHP Skeleton. I think it merges fine.
it also adds two conveniece composer scripts, to start the server/watcher.
What do you think?
Hello @Basster
First of all, thanks so much for that PR. The means that you've been playing for a while with DriftPHP, and this means a lot :)
I've added many points in this PR. You've been so brave with this PR, and opens so many (philosophical) discussion points, what makes sense and seems the right moment to do that.
Remember that DriftPHP aims to use Symfony components and some parts of the application structure, but aims as well to be an independent framework on top of simplicity and architecture decisions.
What do you think? Thanks!
Maybe before going into detail of your review, I want to tell my side of the story:
You started developing a framework on top of another framework, which not only uses its components, but (literally) inherits from its core/kernel. Therefore I'd follow the principles of the parent framework, either way I dislike some of its concepts personally.
Symfony Framework gives a lot of freedom to solve things in different ways and that is one of its main strengths comparing it with some of its competitors.
As you require symfony/framework-bundle: ^5.0 DriftPHP should follow the same principles as its realtive. So mostly I've picked stuff from the official symfony skeleton and placed it here. I'm going to give some examples on each of your comments now.
@Basster
You started developing a framework on top of another framework, which not only uses its components, but (literally) inherits from its core/kernel.
Yes. The core/kernel is a Symfony component, not the framework itself. In this case, the kernel is extending the Symfony one for back compatibility purposes, but the new (and only used) handleAsync method rewrite the whole kernel.
Symfony Framework gives a lot of freedom to solve things in different ways and that is one of its main strengths comparing it with some of its competitors.
Sometimes freedom means caos, and this is one of the things I would like to "change" in this project. I'd like to have one and only one way of solving one problem. And about the competitors thing. The Symfony problem is precisely this. Everything is about competitors. Not my style.
As you require symfony/framework-bundle: ^5.0 DriftPHP should follow the same principles as its realtive.
Why? I'm proposing a different way to solve exactly the same.
To be clear, I'd like to take a decision on top of people feedback. My opinion will be another opinion.
Another personal note:
I found DriftPHP and gave it a try, because it tries to merge concepts from Symfony and ReactPHP and beacuse I found familiar patterns to have an easy start.
Why? I'm proposing a different way to solve exactly the same.
Proposing is fine but forcing devs to follow one single path mostly ends up in rejection, especially if they are still used to the concepts.
Maybe to explain it with the liskov substitution principle, I would expect DriftPHP to behave like Symfony. DriftPHP on the other hand provides more/other values than its ancestor.
That's just my 2 cents.
I think that we misunderstand each other.
Let me explain my position. As I understood the idea behind Drift, that it is not like "async Symfony" but a stand-alone framework on top of ReactPHP and Symfony components. Like Laravel for example. Yes, it seems like it repeats the structure of Symfony (configs, routes) and thus it feels like it should follow Symfony in everything. But I think it was done just for convenience. To show people that they can easily migrate from Symfony to Drift without "rewriting everything".
Talking about OOP: DriftPHP doesn't inherit Symfony and ReactPHP. It is more about composition here.
Hi everyone.
after @seregazhuk comment I see a little clearer and I didn't want to sound so harsh. Sorry about that. I really, really like the idea of DriftPHP and maybe I'm into Symfony for so long, so maybe I just saw something like "async Symfony" in it.
I think we can close this for now. Let me know if I can help you out with anything else.
@Basster Thank you for understanding! I'm glad that now we are on the same page. We really appreciate the work you did! 💪
@Basster to be clear, I don't think you were harsh at all. Open source doesn't mean we have to add the word "please", "thanks" and "IMHO" in every sentence, so if your arguments were for the only for good purposes in terms of the project, the is a good thing :)
Said that, I think that this discussion is not empty at all. I've been the (lonely) lord of the project during months and every single step in the framework has been done because of my perspective. I defend what is my point of view, but each time I need to consider it because of having another point of view in front of me, that enriches me so much.
What I mean is that even I think that @seregazhuk is right, I don't think you're not.
I've always defended that in a framework where software, architecture, and performance are the 3 principal blocks to consider in each PR. For me, the easiest way is not always the best, no matter how many people will just go away from this project because their laziness. Basically because with this philosophy, people that already make an effort to understand a new way is completely abandoned.
Please, consider reopening this PR again. We have time for discussion, and I'm sure more people will have their 5 cents.
Thanks for your work.
Thank you for sharing your perspectives, therefore I'll /reopen it to keep the discussion alive.