You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
registeration of provider in an internal provider's class to singletone provider object map
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.
The text was updated successfully, but these errors were encountered:
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:
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.
The text was updated successfully, but these errors were encountered: