Closed Smoren closed 1 year ago
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Totals | |
---|---|
Change from base Build 4040295367: | 0.003% |
Covered Lines: | 485 |
Relevant Lines: | 486 |
I've added more test cases for Single::keysOnly()
and rebased this branch from develop
.
I've added tests for the Single::index()
.
Hi @Smoren,
Thank you for the PR proposing new functionality.
Can you briefly describe what this functionality is and the use case, and also give a concrete example?
Thanks! Mark
Hi @markrogoyski,
About Single::index()
:
Often, when solving applied problems, I needed to reindex a regular array (for example, a selection from a database), using the IDs of its elements or other fields (and possibly the original indexes in the array) as indexes, sometimes several at once, thus creating a new associative array.
It would seem that the map()
method might be suitable for such things, but it allows you to make a new collection only from values, and not from key and value pairs.
The groupBy()
method is also not fully suitable - its values will always be groups of elements, and we are faced with a second level of nesting, which is not always needed.
About Single::keysOnly()
:
It works similarly to the map()
method, but instead of a callback function, it takes an array of keys whose values we need. However, the map()
method does not allow us to return a collection of key-value format, only an array of values, which is not always convenient.
Sorry, about keysOnly()
: it works a little bit similarly to the compress()
, not map()
, or like a composition of filterTrue()
and map()
(for keys).
Sometimes I tried to seem artificial intelligence, but it doesn't always seem to work :)
Hi @Smoren,
Thank you for the detailed explanation. I think I understand what the intent of the functionality is.
For what you are calling index
, I would describe it like this:
Based on your concrete examples of a database result, I can imagine a unit that that illustrates that use case looking something like this:
/**
* @test reindex
*/
public function testDatabaseReindex(): void
{
// Given
$dbResult = [
[
'title' => 'Star Wars: Episode IV – A New Hope',
'episode' => 'IV',
'year' => 1977,
],
[
'title' => 'Star Wars: Episode V – The Empire Strikes Back',
'episode' => 'V',
'year' => 1980,
],
[
'title' => 'Star Wars: Episode VI – Return of the Jedi',
'episode' => 'VI',
'year' => 1983,
],
];
// And
$reindexFunc = fn (array $swFilm) => $swFilm['episode'];
$result = [];
// When
foreach (Single::index($dbResult, $reindexFunc) as $episode => $swFilm) {
$result[$episode] = $swFilm;
}
// Then
$expected = [
'IV' => [
'title' => 'Star Wars: Episode IV – A New Hope',
'episode' => 'IV',
'year' => 1977,
],
'V' => [
'title' => 'Star Wars: Episode V – The Empire Strikes Back',
'episode' => 'V',
'year' => 19880,
],
'VI' => [
'title' => 'Star Wars: Episode VI – Return of the Jedi',
'episode' => 'VI',
'year' => 1883,
],
];
$this->assertEquals($expected, $result);
}
Based on this, I propose a different name for this function. How about reindex
(definition).
For what you are calling keysOnly
, I initially was thinking this is just filter
but for keys, but if I were to define filterKeys
it would take a callable
that evaluated to true/false, so this is not filterKeys
.
I agree that this is very similar to compress
, as it takes a list of keys to keep and throws the rest away. I like to have similar things to be easily identifiable. With that thought, how are they the same, and how are they different? They are both the same in that they both filter out values according to the selectors provided. They are different in that compress
filters out selected items for an ordered sequential array, where as this new function is filtering out selected items of any kind of key. Therefore, what do you think about calling this compressAssociative
, as in an associative array (PHP's name for a map)?
Thoughts? Mark
Hi @markrogoyski,
Totally agree with you!
Summary of changes:
Single::keysOnly()
renamed to Single::compressAsscoiative()
.Single::index()
renamed to Single::reindex()
.Single::filterKeys()
added and used in the implementation of Single::compressAssociative()
.Single::filterKeys()
method.UPD:
Stream
namespace: methods compressAssociative()
, reindex()
, filterKeys()
were added.Stream
namespace.Stream::toAssociativeArray()
was improved with saving backward compatibility.I've added new methods to CHANGELOG and README files. So I think this PR is ready.
Hi @markrogoyski,
Your arguments sound persuasive.
Methods Single::compressAssociative()
and Stream::compressAssociative()
are simplified.
Hi @markrogoyski, I've rebased this branch from develop
and resolved the conflicts.
Hi @markrogoyski,
I've added new methods to the
Single
namespace.If you like them, I'll add all the necessary tests and docs.