Re: Assess acceptability of having php-ds into core
| From: | Larry Garfield | Date: | Mon, 16 May 2016 01:46:06 +0000 |
| Subject: | Re: Assess acceptability of having php-ds into core | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-93347@lists.php.net to get a copy of this message | ||
On 05/12/2016 08:27 PM, guilhermeblanco@gmail.com wrote:
Hi internals, PHP 7 leverages a lot the performance internally and many PHP applications in the wild. Much of these improvement came by experimentation through PHPNG and the usage of efficient data structures internally. This idea of performance improvements are crucial to handle more requests, reduce server overload, etc. However, what lacks in PHP is the exposure of more efficient, use case specific data structures, that could allow end users to easily improve performance of their applications, instead of using a general, multi-purpose data structure that we have as "array". Based on that (please keep in mind I haven't spoken with library author), I'd like assess the receptability of incorporating php-ds library into core. Library author wrote a good (and lengthy) article explaining his motivation and performance benchmarks around it. Here are the related links: Article: https://medium.com/@rtheunissen/efficient-data-structures-for-php-7-9dda7af674cd Extension: https://github.com/php-ds/extension Polyfill: https://github.com/php-ds/polyfill Tests: https://github.com/php-ds/tests Benchmark: https://github.com/php-ds/benchmarks Best regards,I am all for more efficient and performant tools being available natively. However, the php-ds extension in particular, while it sounds very nice, is still missing what I believe are key collection-related operations, that is, set-level operations. The equivalents of array_map, array_filter, first(callable) (ie, the first item that passes a given callable condition), etc. are all extremely powerful collection-level, functional operations. We have array-based versions and have for many years, but having them on formal collections or objects has always been a sore point, and run into various road blocks of "arrays aren't objects", "but then we can't extend the set of operations", etc. The pipe syntax currently being discussed helps some, but it's not as clean as doing it natively. If we're going to improve the quality of our native collection tools, then a richer set of operations (for which there is a known list of common operations from most functional languages) needs to be part of that discussion. --Larry Garfield