nmeri17 / suphle

Opinionated PHP framework for building performant, extensible, and testable web applications
http://angry-cray-9c191b.netlify.app/
MIT License
33 stars 0 forks source link

Need to upgrade to PHP 8 #35

Closed nmeri17 closed 1 year ago

nmeri17 commented 2 years ago

There's a lot of talk about PHP 7 becoming legacy by next month. I tried running the tests on PHP 8 but got a lot of funny errors even though entire source is strictly typed. Suphle is built with PHP 7 both because that was the highest version at the time of its inception and even after PHP 8 launched, I preferred to maintain it that way to lower barrier of entry. Another incentive is that none of the features between 8.1-3 have been indispensable to my work.

There is but one dated package I'm using for queues: anorgan/qutee, since I'm unable to find any other one that allows a flexible task class /arguments API. I added a forked repository in Suphle's composer.json. I've opened a pull request since last year, mailed the author, all to no avail. I imagine dependencies will equally require compatibility with version 8. So I'm thinking, if a modern alternative to this package is viable, you can get rid of the dependency and replace its [adapter] (https://github.com/nmeri17/suphle/blob/5155c68eb817500af29ae078ddfe571cf6d12554/src/Adapters/Queues/QuTee.php).

My hands are tied with work on the documentation since it's release is long overdue. I may not have the time to automate an upgrade using Rector. I've not used it before and can't tell how long it'll distract me. Any help I can get help with that would be appreciated

nmeri17 commented 2 years ago

Closing this as Suphle has been upgraded over the series of commits leading up to this https://github.com/nmeri17/suphle/commit/9ce98bf5f1ec1179cc6b8da70b464fa0a1e2cb72. However, the queue adapter issue still stands and is open to replacement

nmeri17 commented 1 year ago

Alright, I'm reopening this because we're only php 8 compatible on paper. It's not enough to refactor in some php 8 syntaxes. As of now, the container won't know what to do if a type-hinted parameter uses any of the new types (union, intersection, enums). Secondly, and perhaps relatively easier, decorator application should be ported from interfaces to native attributes, since the community is apparently leaving php 7.4 behind anyway

This is the two that come to mind. Any assistance with them is welcome

nmeri17 commented 1 year ago

Ported decorators from interfaces to native attributes. Can't instantiate enums. Deliberately not supporting union and intersection types cuz they breed the same ambiguity that mixed typing does.

Php 8 compliant, in my book