rfc:vector

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
rfc:vector [2021/09/24 00:49] – tandrerfc:vector [2021/09/26 16:46] (current) – php-ds maintainer response tandre
Line 1: Line 1:
 ====== PHP RFC: final class Vector ====== ====== PHP RFC: final class Vector ======
-  * Version: 0.1+  * Version: 0.2
   * Date: 2021-09-16   * Date: 2021-09-16
   * Author: Tyson Andre, tandre@php.net   * Author: Tyson Andre, tandre@php.net
Line 325: Line 325:
 ===== Rejected Features ===== ===== Rejected Features =====
  
-==== Why not use php-ds instead? ==== +==== Why not use php-ds/ext-ds instead? ====
  
     - No matter how useful or popular a PECL is, datastructures available in PHP's core will have much, much wider adoption in applications and libraries that are available in PECLs, allowing those applications and libraries to write faster and/or more memory efficient code.     - No matter how useful or popular a PECL is, datastructures available in PHP's core will have much, much wider adoption in applications and libraries that are available in PECLs, allowing those applications and libraries to write faster and/or more memory efficient code.
     - End users can make much stronger assumptions about the backwards compatibility and long-term availability of data structures that are included in core.     - End users can make much stronger assumptions about the backwards compatibility and long-term availability of data structures that are included in core.
-    - The php-ds maintainers do not plan to merge the extension into php-src (see quote for full context)+    - The php-ds maintainers do not plan to merge the extension into php-src, and believe php-ds should coexist with new functionality being added in a separate namespace instead (see quote and [[##updatephp-ds_maintainer_response_clarifications|later clarifications]] for full context)
     - Opcache may be able to make stronger optimizations of internal classes found in php-src than any third party PECL. (e.g. because ''Deque::push()'' or ''Vector::push()'' would never throw or emit notices, it may be possible to optimize it to be even faster than appending to an array in the Opcache JIT compiler)     - Opcache may be able to make stronger optimizations of internal classes found in php-src than any third party PECL. (e.g. because ''Deque::push()'' or ''Vector::push()'' would never throw or emit notices, it may be possible to optimize it to be even faster than appending to an array in the Opcache JIT compiler)
  
Line 388: Line 387:
 It's definitely a mature project, but I personally feel like reimplementing this (without referring to the php-ds source code and without copying the entire api as-is) is the best choice to add efficient data structures to core while respecting the maintainer's work on the php-ds project and their wish to maintain control over the php-ds project. It's definitely a mature project, but I personally feel like reimplementing this (without referring to the php-ds source code and without copying the entire api as-is) is the best choice to add efficient data structures to core while respecting the maintainer's work on the php-ds project and their wish to maintain control over the php-ds project.
  
-As a result, I've been working on implementing data structures such as ''Deque'' and ''Vector'' based on php-src's data structure implementations (mostly ''SplFixedArray'' and ''ArrayObject'') instead (and based on my past PECL/RFC experience, e.g. with ''runkit7''/''igbinary'')+As a result, I've been working on implementing data structures such as ''Deque'' based on php-src's data structure implementations (mostly ''SplFixedArray'' and ''ArrayObject'') instead (and based on my past PECL/RFC experience, e.g. with ''runkit7''/''igbinary'')
  
 === Minor differences in API design goals === === Minor differences in API design goals ===
Line 418: Line 417:
 Additionally, it may be inconvenient for end users (e.g. new contributors to projects) to remember specifics of multiple libraries or utility classes when working on different codebases, to deal with dependency conflicts after major version upgrades, or to deal with libraries dropping support for older php versions, getting abandoned, etc. Additionally, it may be inconvenient for end users (e.g. new contributors to projects) to remember specifics of multiple libraries or utility classes when working on different codebases, to deal with dependency conflicts after major version upgrades, or to deal with libraries dropping support for older php versions, getting abandoned, etc.
  
 +==== Update: php-ds maintainer response clarifications ====
 +
 +On September 24, 2021, [[https://github.com/php-ds/ext-ds/issues/156#issuecomment-926353779|the maintainer responded]] after being asked about current plans for php-ds
 +
 +<blockquote>
 +Hi everyone, I am happy to see this discussion and I thank you all for taking part. My reservation to merge ds into core has always been because I wanted to make sure we get it right before we do that and the intention behind the mythical v2 was to achieve that, based on learnings from v1 and feedback from the community. I have no personal attachment to this project, I only want what is best for PHP and the community.
 +
 +I would love to see a dedicated, super-lean vec data structure in core that has native iteration and all the other same internal benefits as arrays. In my opinion, the API should be very minimal and potentially compatible with all the non-assoc array functions. An OO interface can easily be designed around that. I'm imagining something similar to Golang's slices.
 +
 +**As for the future of ds itself, I think these can co-exist and ds can remain external. I've been researching and designing immutable data structures over the last 4 years and I still hope to develop a v2 that simplifies the interfaces and introduces immutable structures. Attempting to implement a suite of structures in core or an OO vector would take a lot of work and might be difficult to reach consensus on with the API. I don't think we should attempt to merge ds into core at any time.**
 +
 +I am currently traveling and have not followed this discussion in detail on the mailing list. I'd be happy to assist in any way I can and will catch up as soon as I am home again this week. Feel free to quote this response on the mailing list as well.
 +</blockquote>
 +
 +I'm still awaiting some clarifications on how they they were willing to assist before updating the remainder of this RFC.
 +
 +Additionally, there may be differences in design goals, as noted in the above section.
  
 ==== Adding a native type instead (is_vec) ==== ==== Adding a native type instead (is_vec) ====
Line 445: Line 461:
  
 Also, even if a type ''vec'' or ''array'' were added, ''vec'' and ''array'' would be distinct types - a vec couldn't be passed to a parameter that expected an array reference (or returned in a return value), because later adding a string array key (in the parameter or return value) would be a runtime error. Also, even if a type ''vec'' or ''array'' were added, ''vec'' and ''array'' would be distinct types - a vec couldn't be passed to a parameter that expected an array reference (or returned in a return value), because later adding a string array key (in the parameter or return value) would be a runtime error.
 +
 +==== Changelog ====
 +
 +0.2: Add php-ds maintainer response, improve documentation, note this is on hold while working on ''Deque'' (Double-Ended Queue) RFC
  
rfc/vector.1632444597.txt.gz · Last modified: 2021/09/24 00:49 by tandre

Page Tools