-
Notifications
You must be signed in to change notification settings - Fork 361
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
[Modifiers] Helper methods to use our custom generators #155
Conversation
Probably best to rebase on top of |
src/Faker/Generator.php
Outdated
* | ||
* @return self The UniqueGenerator is a proxy | ||
*/ | ||
public function withUnique() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
public function withUnique() | |
public function withUnique(): self |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But this is technically not true. (And also why psalm is complaining).
The UniqueGenerator
and other generators will implement the magic method __call()
. They can be used and treated as they are a Generator
but they are not really.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we agreed to do away with magic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everywhere but the proxy generators. Im not sure how to implement the Modifiers without them proxying calls to Generator.
I would be super happy to get a suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't the UniqueGenerator
just an implementation of a generator, hence returning self
would be correct, since it extends generator?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No not really. It is a proxy. It does not extend.
src/Faker/Generator.php
Outdated
|
||
public function __construct() | ||
{ | ||
$this->uniqueGenerator = new UniqueGenerator($this); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Each Generator instance has a UniqueGenerator
. So I can run:
$faker->name(); // Might be 'Alice'
$faker->withUnique()->name(); // Might be 'Bob'
$faker->name(); // Might be 'Alice' again
$faker->withUnique()->name(); // Might be anything but 'Bob'
If we were about to create a new UniqueGenerator
each time we called withUnique()
, we could not guarantee it's uniqueness. Unless we used static variables, but then the uniqueness would be global and not specific to a instance of the Generator
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of reimplementing the behaviour here, what do you think about moving methods from Faker\Provider\Base
to Faker\Generator
one by one, guided by tests?
Also see #233.
Maybe I have overlooked something, but I think there's a bug here now when calling (new Generator())->withMaybe(0)->ext(\Faker\Extension\FileExtension::class)->mimeType() throws |
Excellent @krsriq, You are correct. That is something I have not thought about. How do you suggest we fix that? |
src/Faker/Generator.php
Outdated
|
||
public function __construct() | ||
{ | ||
$this->uniqueGenerator = new UniqueGenerator($this); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of reimplementing the behaviour here, what do you think about moving methods from Faker\Provider\Base
to Faker\Generator
one by one, guided by tests?
Also see #233.
We have a related problem here in $generator->withUnique()->ext(\Faker\Extension\FileExtension::class)->mimeType() may return duplicate results. The issue here is that the Unfortunately I have not yet found a solution for these problems, I'll keep digging.. |
@Nyholm okay, I found a way to do this for the we basically want to be able to differentiate between a call to This is just a proof-of-(a-bad-)concept and could definitely be improved (or a cleaner solution be found), but it means that it's not impossible to use extensions with these generators. |
What are the plans with this? Since this is crucial on the design right? |
4d79099
to
07f511a
Compare
I think I've solved the extension stuff. Please have a look. I took @krsriq idea and continued working on it. |
I think the usecase is not resolved yet: for ($i=0; $i<6;$i++) {
echo $faker->unique()->ext(\Faker\Extension\BloodExtension::class)->bloodGroup().PHP_EOL;
} A+
AB+
AB+
AB-
O+
O+ @Nyholm am i missing something here? |
This has been fixed now. |
The issue with |
LGTM What does the rest think? I think this is the last topic before splitting it to seperate language packs right? |
This will add real methods to use our custom generators. They are described in https://github.com/Nyholm/next-faker#modifiers