cocur / chain Goto Github PK

This would also be a great addition:
http://php.net/manual/fr/function.natcasesort.php

I'm not sure what's best:

• implementing it as a method
• making it an option of the existing sort method

Also you may also consider other case insensitive operations like a CI unique and intersect.

Fill is actually a Trait.
https://github.com/cocur/chain/blob/master/src/Link/Fill.php

This is the only Trait that don't operate on an instance and also the only one that is static.
Other Traits are all instance methods, this one is a factory.

This code should be moved to the Chain class which host other factory methods create and createFormString. This would be an entirely transparent change, it would make the code more consistent and would prevent statistical analysis failing:

https://scrutinizer-ci.com/g/cocur/chain/inspections/fba87ae0-dc03-4190-966a-64fd5f908b9b/issues/files/src/Link/Fill.php?status=all&orderField=path&order=asc&honorSelectedPaths=0

map()s callable receives two arguments, the value and its index. This makes using standard library functions like trim and intval problematic without wrapping them in an anonymous or arrow function (because those functions have a second argument that alters behaviour).

It would be useful to have an alternative map() that does not supply the index. Without breaking the API this would need to be something like mapValue(), whereas it might have been preferable to have map() and mapWithIndex().

In part, the lack of documentation for each of Chain's methods, in regards to the Callable's parameters, doesn't help, without digging into the source.

I have a scenario where i need to merge multiple domain value objects and it would be handy if one could just do:

Chain::merge($object->getOutsidePhotos(), $object->getInsidePhotos())
    ->map(fn (Photo $photo) => $photo->getUrl())
    ->map(fn (string $url) => $this....);

compared to:

Chain::create(array_merge($object->getOutsidePhotos(), $object->getInsidePhotos()))
    ->map(fn (Photo $photo) => $photo->getUrl())
    ->map(fn (string $url) => $this....);

Also different function of merge can be implemented, for example according to Optimizing array merge operation you will get better speed if you do not use the array_merge function in large arrays, because of some conditions php check internally.

What do you think?

It will be useful if Chain will implement JsonSerializable interface to use Chain values in json_encode.

Drop support for PHP < 7.1.
https://www.php.net/supported-versions.php

This will make possible to add strong typing and return types everywhere.

It would be good if generics are added, for better static analysis. For example, the find method should return T|false.

Reference: https://phpstan.org/blog/generics-in-php-using-phpdocs

It would be great if a join or implode method could be added. The Link would work like implode($glue, $array).

$array = [1, 2, 3];

Chain::create($array)->join('&'); // "1&2&3"

When you filter an array, it may become 'sparse'. PHP deals with this situation by turning it to an associative array:
https://eval.in/916518

<?php
$a1 = ['a', 'z', 'e', 'r', 't', 'y', 'u', 'i', 'o', 'p', 'q', 's', 'd'];
$a2 = ['a', 'z', 'e', 'r', 't', 'y', 'u', 'i', 'o'];

echo json_encode(array_filter($a1, function($i){ return $i != 's'; }));
echo json_encode(array_filter($a2, function($i){ return $i != 's'; }));

{"0":"a","1":"z","2":"e","3":"r","4":"t","5":"y","6":"u","7":"i","8":"o","9":"p","10":"q","12":"d"}
["a","z","e","r","t","y","u","i","o"]

This is really disturbing and unintuitive, no other language (AFAIK) do that. I know PHP always had this permanent confusion between lists and maps, but this doesn't feel right: if I filter a list I should get a filtered list in return.

Would you consider adding a boolean argument forceList or adding a filterList method who always return array_values in the internal state ?

A flatMap method would be really handy.

I made a matrix comparing JS array API, PHP anc Chain.
I've matched the methods when possible.
I haven't dig into JS objects API, nor lodash or reactivex yet.

What I think needs to be implemented:

• includes (in_array)
• every
• flat
• some
• range
• chunk
• pluck
• firstKey
• lastKey
• walk / tap / peek, not sure about the name

I also noticed that diff and intersect needs some work, some modes aren't supported. Also it would be nice to keep consistency with what has been done in sort.

What's your opinion about that ?

Tooling is out of date and cause tests to fail:

• travis for HHVM fails because composer dropped support:
  composer/composer#8127
  You should probably drop it too.
• travis for nightly fails because there´s currently no stable release of phpUnit supporting PHP8
  IMHO you should temporarly disable nightly and update to current phpUnit release
• appveyor fails because php version has been bumped from 7.2 to 7.3

If you want I can take some time to provide a PR.

PHP 8.1 requires the offsetGet function to be compatible with the ArrayAccess declaration, i.e. to have a mixed return type. Without this, the Chain library produces deprecation notices like this:

PHP Deprecated:  Return type of Cocur\Chain\AbstractChain::offsetGet($offset) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in .../vendor/cocur/chain/src/AbstractChain.php on line 46

Mixed type is only available in PHP 8, Chain supports 7.2, so the only way to meet the new requirements is to add the #[\ReturnTypeWillChange] attribute.

Please add a find method.

The Values Trait is never imported in Chain, trying to use it will spawn a Fatal error: undefined method.