I am about to start working on my own full-stack framework, but as a micro framework I think PIMF has promise. If we can keep it running fast while improving the code structure, version 2 will be great.
I like the idea of using a DIC, but I can understand why you think it's not a good fit. Can you tell me what DIC packages you like? That may help me understand how it would complicate things.
Even if we do not use a DIC, I think there is still probably room for improvement in the OOP area.
I have been working for log time in some projects with:
- Yadif DIC (https://github.com/tsmckelvey/yadif)
- Symfony’s DIC
- But anyway. If you want to make improvements in the OOP area of PIMF, please feel free do it. And if you are thinking that implementing some lightweight DIC (or better some kind of “ Inversion-Of-Control paradigm”) will make PIMF faster, also feel free to do it. After that it will be helpful if we can see some benchmark results like PIMF-before vs. PIMF-after DIC implementation.
I've never heard of Yadif, but I do know that Symfony's DIC is quite slow, so I wouldn't want to use that.
I have been working with an IoC container called Dice for some time (https://github.com/Level-2/Dice) and it is quite fast. I don't think any DIC will actually improve speed, but the best one would make development easier while being lightweight so as to not slow things down.
I have been working with an IoC container called Dice for some time (https://github.com/Level-2/Dice) and it is quite fast. I don't think any DIC will actually improve speed, but the best one would make development easier while being lightweight so as to not slow things down.
I will look at this Yadif to see how it works.
Here is an article showing some benchmarks of popular DICs but it is 2 years old.
https://www.sitepoint.com/php-dependency-injection-container-performance-benchmarks/
https://www.sitepoint.com/php-dependency-injection-container-performance-benchmarks/
Interesting IoC container! Is significantly faster than other popular libraries. For some years I also played around with DI + DIC and IoC, please check it out. Maybe it helps https://github.com/gjerokrsteski/php-di-dic-ioc
FYI: SensioLabsInsight couldn't find a single violation in the whole codebase of this project https://insight.sensiolabs.com/projects/f73307c6-0864-454f-967d-cebfd1e4b304/analyses/163
Update forked PIMF Git repository
If you want to update your own fork of a repo with some repos upstream,than you should be able to clone your repo, add a new remote as upstream,
then merge your master with the upstream master.
# upstream is the name which you give to the remote
git remote add upstream git@github.com:gjerokrsteski/pimf-framework.git
git fetch upstream
# prefer using "git rebase upstream/master master" in order to avoid a merge commit if possible
git merge upstream/master master
git push origin master
It does everything at once
(except for
push)
my idea is if all changes from issue-23 are made and all tests are green, than to release a new latest version PIMF v1.10.1 and to update all budels on PIMF v1.10.1 OK?
(1) What is your reason for using git submodules and not Composer dependencies?
(2) Are you opposed to tweaking the directory structure? I just read about the reasoning behind Symfony 4's structure and I would like to borrow a few ideas from that, as it seems built for scalable usage.
(2) Are you opposed to tweaking the directory structure? I just read about the reasoning behind Symfony 4's structure and I would like to borrow a few ideas from that, as it seems built for scalable usage.
(I feel like using third-party libraries would make pimf more robust without much effort.)