Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v4? #675

Open
pkly opened this issue Jun 2, 2022 · 0 comments
Open

v4? #675

pkly opened this issue Jun 2, 2022 · 0 comments

Comments

@pkly
Copy link

pkly commented Jun 2, 2022

Hello.

We've implemented omnipay as v3 about 2 years ago now, and it works fine for the most part.
I was wondering if you were considering a new major version which would require a rework?

Things to consider:

  • The base Omnipay http client implementation uses a custom http client interface It would be entirely possible to simply move to PSR-18 along with http client discovery, and http-message-factory interfaces, thus allowing any framework to simply plug in an implementation, and dropping guzzle as a requirement.

This is a breaking change, as the client requirements would change along with the exceptions thrown.
I would propose also no default client to be added, instead by going along with what composer wants us to do simply require an implementation.
This would allow omnipay to completely decouple from http requests.

  • The gateways are created statically and sit in a "main" namespace, with logic that will create objects in a rather strange way

This should likely be just removed, instead the gateways should implement a main interface and sit in separate namespaces.
A "shared" main namespace could still be considered for official gateways.

The methods for gateways could be split into interfaces instead of an annotation, thus having a proper requirement of implementation on the gateway and allow someone to simply do a $gateway instanceof PurchaseGatewayInterface

  • No more setters/getters into infinity that are a hard requirement

By requiring php 8.1 or simply moving some of the logic elsewhere it would be possible to stop using the set/get pattern along with likely dropping the requirement for ParameterBag and by thus I believe the symfony-framework?
If still needed it would be wise to maybe consider an alternative, or simply store parameters in an array.

  • There's little to any input validation

I'm currently on implementing another gateway for our project and I noticed that barely anything typechecks, as omnipay was designed to work with... php5?

  • Updating language features

At a time like this it seems a good idea to jump straight to php8.1 allowing a greater freedom of choice and improving development experience. The project could also use an upgrade of all libraries in use (omnipay/tests still uses phpunit 6...)

  • Updating quality tools, ensuring templates and so on

As code evolves it would be a good idea to use phpstan, psalm and so on as quality assurance tools.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant