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

Make providers SPI friendly #869

Open
snuyanzin opened this issue Jun 19, 2023 · 0 comments
Open

Make providers SPI friendly #869

snuyanzin opened this issue Jun 19, 2023 · 0 comments

Comments

@snuyanzin
Copy link
Collaborator

Is your feature request related to a problem? Please describe.
This is mostly related to custom providers.
The main issue is that currently any custom provider should be registered in Faker. Only after that it could be used.
The registration process consists of 2 things:

  1. registeration of provider in an internal provider's class to singletone provider object map
  2. a new method which could be used to access provider from faker.

The second step could be considered optional if we do NOT work with expressions. However it is required for expressions since under the hood faker works with reflections and assumes existence of such methods to get provider.

From the other side since we could create providers map earlier (e.g. static) and every faker could just reuse it since it is assumed to be not changed or just new custom providers to be added (no updates, no deletes).
It could be initialized once based on SPI data and then only some custom fakers could be added (which do not follow SPI approach) in case this update was initiated explicitely in code.

Then this map could be used to get provider by class and no need for having a special method from step 2 here, so one less reflection call here.

In theory this should speed up a bit expressions,
no change for non expressions is expected here.

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