Hi Pierre, > It seems that you are writing more than one RFC to add many data > structures. I love that you're doing that, but I suggest that you'd > normalize them all
I'm not certain what you mean by "normalize". https://www.merriam-webster.com/dictionary/normalize mentions 1. "to make conform to or reduce to a norm or standard" 2. https://www.freetext.org/Introduction_to_Linear_Algebra/Basic_Vector_Operations/Normalization/ (no pun intended) 3. "to bring or restore to a normal condition" If you mean to make Vector and Queue's APIs consistent with each other, I plan to make changes to Vector (e.g. remove $preserveKeys, add isEmpty), but the Vector RFC is currently on hold. If you also mean all datastructure RFCs should be combined into a single RFC, I'd considered combining the Vector RFC with https://wiki.php.net/rfc/deque, but decided against combining the RFCs in this instance, because of: 1. Current discussion about whether or not to choose an alternate name for a `Vector` 2. The fact that `Deque` has much better performance for various queue workloads on both time and memory usage than `array` (and significantly better performance than `SplDoublyLinkedList`). Still, I may consider the approach for future RFCs, given that 1. Many developers in internals have expressed a desire for having a significantly larger data structure library in core along the lines of what php-ds provides, but may be uninterested in some of the individual datastructures or design choices. E.g. if 60% of developers were in favor of a sorted set and its proposed API/name (along the lines of https://cplusplus.com/reference/set/set/), 60% were in favor of an immutable sequence and its proposed API/name (of values) (similar to https://docs.python.org/3/tutorial/datastructures.html#tuples-and-sequences), then with the 2/3 voting threshold, neither of those RFCs would pass but a proposal combining those two would pass, despite ~95% of developers wanting some type of improved datastructures added to core in general (I would guess). 2. This would allow seeing how datastructures compare to each other. Combining RFCs has the drawback of significantly increasing the implementation, discussion, review, delays, and time involvement for the volunteer RFC authors and voters, and may lead to a larger number of last-minute concerns raised after voting has started when more time is spent trying out the new code and looking at the RFC. > and place all new classes in a single new dedicated > namespace. My rationale for deciding against a dedicated namespace is in https://wiki.php.net/rfc/deque#global_namespace which I've recently expanded on. The `Deque` proposal is normalized with respect to the namespace choice of data structures that already exist. The choice of global namespace maintains consistency with the namespace used for general-purpose collections already in the SPL (as well as relatively recent additions such as ''WeakReference'' (PHP 7.4) and ''WeakMap'' (PHP 8.0)). Other recent additions to PHP such as ''ReflectionIntersectionType'' in PHP 8.1 have also continued to use the global namespace when adding classes with functionality related to other classes. Additionally, prior polls for namespacing choices of other datastructure functionality showed preferences for namespacing and not namespacing were evenly split in a straw poll for a new iterable type (https://wiki.php.net/rfc/cachediterable_straw_poll#namespace_choices) Introducing a new namespace for data structures would also raise the question of whether existing datastructures should be moved to that new namespace (for consistency), and that process would: 1. Raise the amount of work needed for end users or library/framework/application authors to migrate to new PHP versions. 2. Cause confusion and inconvenience for years about which namespace can or should be used in an application (''SplObjectStorage'' vs ''Xyz\SplObjectStorage''), especially for developers working on projects supporting different php version ranges. 3. Prevent applications/libraries from easily supporting as wide of a range of php versions as they otherwise could. 4. Cause serialization/unserialization issues when migrating to different php versions, if the old or new class name in the serialized data did not exist in the other php version and was not aliased. For example, if the older PHP version could not ''unserialize()'' ''Xyz\SplObjectStorage'' and would silently create a `__PHP_Incomplete_Class_Name` (see https://www.php.net/manual/en/language.oop5.serialization.php#language.oop5.serialization) without any warnings or notices. Thanks, Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
