Re: RFC: Add `final class Vector` to PHP

Hi Christian Schenider, > First of all: I don't have a strong opinion on a Vector class being useful or necessary. > > But I have two comments about this RFC: > > 1. Using the very generic name Vector without any prefix/namespace seems dangerous and asking > for BC breaks. I downloaded the top 400 composer packages with https://github.com/nikic/popular-package-analysis/ and didn't find any classes named Vector. - Only php-cs-fixer extends SplFixedArray in one class. It can continue do so. - I don't see other classes called Vector. Just stubs for \Ds\Vector. There are tradeoffs and objections to any possible choice of name I could make, including this or alternates. - Too likely to have conflicts - Excessively long - Open to adopting namespace but objecting to migrating existing classes (or not doing so) - Objecting to a specific choice > 2. I don't like that this class is final. The reasons given in > https://wiki.php.net/rfc/vector#final_class > https://wiki.php.net/rfc/vector#final_class seem unconvincing to me and restrict the usage of Vector > in a way which makes me question the usefulness to a big enough part of the PHP community. > These two reasons combined would make me reject the RFC at the current stage. There are alternatives such as making all/almost all of the methods final(especially for reading and modifying array elements or basic properties of the vector), but allowing extending the class. - Still, I don't think that'd be very useful, and would make future final method additions to Vector backwards incompatible. - Trying to do everything (e.g. be extensible and handle all edge cases of extension) has often resulted in many spl data structures doing not anything very well(efficiently, correctly, or possible to make universal assumptions about or optimize in the future with opcache/the jit). While it is possible to extend ArrayObject and SplFixedArray, very few things do that, and it'd generally lead to worse API design except in a few cases. (E.g. UserList extends \Vector wouldn't be able to enforce that inserted values are actually users with final methods) Thanks, Tyson