Closed ezzatron closed 3 months ago
Just adding a comment here to get notifications about this issue since I'm also interested about this concern. Indeed we already had a debate around it but we didn't find any consensus yet.
I'm still holding out hope that arrow functions will make for a nicer syntax for this use-case 🤞
@ezzatron have you checked out https://preprocess.io?
Looks cool 👍
I think the concept of data providers is something that lots of people will look for when switching from PHPUnit to Peridot. I think I brought it up with @brianium during our first get-together, and there's #183 and peridot-php/peridot-core#16 related to this issue already.
I had a conversation with my friend @koden-km about how to migrate some PHPUnit tests that use Data Providers over to Peridot.
We came up with a solution that utilized an associative array and a
foreach
loop. Here's some sample code:This produces output like this:
This approach isn't too bad, but I think that's partly because this scenario only has one input to each test (
$statistics
). If each test required multiple inputs, either the inner closure would have to expand its list ofuse
'd variables, or it would have to accept all inputs in a singleuse
'd array/object, then access each by index/property.I looked for some prior art to guide us in implementing this feature. It seems as though the typical JavaScript approach is similar to this:
Unfortunately, this doesn't map to PHP very well because of the fact that PHP's closures don't automatically inherit variables from the parent scope. That is, at least until the Arrow Functions RFC is implemented.
Maybe this calls for a new Peridot feature that could somehow exploit setDefinitionArguments(). There's a definite challenge though, as plugins like peridot-phony also use this method for injecting other arguments.
Even if we make no code changes, I think having some solid documentation for how to achieve this kind of setup would help newcomers to justify the switch to Peridot.