> Improving collection/set operations in PHP is something near and dear to my > heart, > so I'm in favor of adding a Vector class or similar to the stdlib. > > However, I am not a fan of this particular design. > > As Levi noted, this being a mutable object that passes by handle is asking > for trouble. > It should either be some by-value internal type, or an immutable object with > evolver methods on it. > (E.g., add($val): Vector). Making it a mutable object is creating spooky > action at a distance problems. > An immutable object seems likely easier to implement than a new type, > but both are beyond my capabilities so I defer to those who could do so.
https://wiki.php.net/rfc/vector#adding_a_native_type_instead_is_vec discusses why I'm doubtful of `is_vec` getting implemented or passing. Especially with `add()` taking linear time to copy all elements of the existing value if you mean an array rather than a linked list-like structure, and any referenced copies taking a lot more memory than an imperative version would. PHP's end users and internals members come from a wide variety of backgrounds, and I assume most beginning or experienced PHP programmers would tend towards imperative&mutable programming rather than functional&immutable programming. PHP provides tools such as `clone`, private visibility, etc to deal with that. The lack of any immutable object datastructures in core and the lack of immutable focused extensions in PECL https://pecl.php.net/package-search.php?pkg_name=immutable https://www.php.net/manual-lookup.php?pattern=immutable&scope=quickref (other than DateTimeImmutable) heavily discourage me from proposing anything immutable. (Technically, https://github.com/TysonAndre/pecl-teds has minimal implementations of immutable data structures, but the api is still being revised and Vector is the primary focus, followed by iterable functions. e.g. there's no `ImmutableSequence::add($value): ImmutableSequence` method.) > The methods around size control are seemingly pointless from a user POV. setSize is useful in allocating exactly the variable amount of memory needed while using less memory than a PHP array. `setSize($newSize, 0)` would be much more efficient and concise in initializing the value. - Or in quickly reducing the size of the array rather than repeatedly calling pop in a loop. And while methods around capacity control exist in many other programming languages, they aren't used by most users and most users are fine with functionality they don't use existing. The applications or libraries that do have a good use case to reduce memory will take advantage of them and end users of those applications/libraries would benefit from the memory usage reduction. > I understand the memory optimization value they have, but that's not > something PHP developers are at all used to dealing with. > That makes it less of a convenient drop-in replacement for array and more > just another user-space collection object, but in C with internals > endorsement. > If such logic needs to be included, it should be kept as minimalist as > possible for usability, > even at the cost of a little memory usage in some cases. If the functionality was just a drop-in replacement for array, others may say "why not just use array and the array libraries?" (or Vector). With the strategy of doubling capacity, it can be up to 99% more memory than needed in some cases (Even more wastage after shrinking from the maximum size). > There is no reason to preserve keys. > A Vector or list type should not have user-defined keys. > It should just be a linear list. If you populate it from an existing > array/iterable, the keys should be entirely ignored. > If you care about keys you want a HashMap or Dictionary or similar (which we > also desperately need in the stdlib, but that's a separate thing). The behavior is similar to https://www.php.net/manual/en/splfixedarray.fromarray.php It tries to preserve the keys, and fills in gaps with null. 1. There's the consistency with existing functionality such as SplFixedArray::fromArray, or existing constructors preserving keys. 2. And I'd imagined that a last minute objection of "Wait, `new SplFixedArray([1 => 'second', 0 => 'first'])` does what by default? Isn't this using the keys 0 and 1?", and the same for gaps I was considering only having the no-param constructor, and adding the static method fromValues(iterable $it) to make it clearer keys are ignored. > Whether or not contains() needs a comparison callback in my mind depends > mainly on whether or not the operator overloading RFC passes. > If it does, then contains() can/should use the __compareTo() method on > objects. > If it doesn't, then there needs to be some other way to compare non-identical > objects or else that method becomes mostly useless. There's a distinction between needs and very nice to have - a contains check for some predicate on a Vector can be done with a userland helper method and a foreach. Also, you're requesting functionality that I don't believe is currently available for arrays, either. > To echo Pierre, a Vector needs to be of a single guaranteed type. > Yes, this gets us back to the generics conversation again, but I presume > (perhaps naively?) there are ways to address this question without getting > into full-blown generics. Yep, as you said, this type is mixed, just like the SplFixedArray, ArrayObject, values of SplObjectStorage/WeakMap, etc. Generic support is something that's been brought up before, investigated, then abandoned. My concerns with adding StringVector, MixedVector, IntVector, FloatVector, BoolVector, ArrayVector (confusing), ObjectVector, etc is that - I doubt many people would agree that there's a wide use case for any specific one of them compared to a vector of any type. This would be even harder to argue for than just a single Vector type. - Mixes of null and type `T` might make sense in many cases (e.g. optional objects, statistics that failed to get computed, etc) but would be forbidden by that - It would be a bad choice if generic support did get added in the future. I'm not sure if we're thinking of the same thing. Could you provide more details on how that would be implemented? Have other PECLs done something similar? > But really, a non-type-guaranteed Vector/List construct is of fairly little > use to me in practice, and that's before we even get into the potential > performance optimizations for map() and filter() from type guarantees. See earlier comments on `vec`/Generics not being actively worked on right now and probably being a far way away from an implementation that would pass a vote. As for optimizations, opcache currently doesn't optimize individual global functions (let alone methods), it optimizes opcodes. Even array_map()/array_filter() aren't optimized, they call callbacks in an ordinary way. E.g. https://github.com/php/php-src/pull/5588 or https://externals.io/message/109847 regarding ordinary methods. Aside: In the long term, I think the opcache core team had a long-term plan of changing the intermediate representation to make these types of optimizations feasible without workarounds like the one I proposed in 5588 > I can write a type-guaranteed user-space class that does what I need in under > 10 minutes, and for most low cardinality sets that's adequately performant. A > built-in needs to be better than that. > > I very much appreciate the chicken-and-egg challenge of wanting to get > something useful in despite the absence of a larger plan, and also the > challenge of getting buy-in on a larger plan. > Really. :-) This is an area where PHP's current dev process is very lacking. > Still, I also agree with others that we need to be thinking holistically > about this problem space, which will inform what the steps are. > The approach we took for enums could be a model to consider (multiple RFCs > clustered together under an RFC "epic".) > That would allow for a long-term design, and the influence that offers, while > still having milestones along the way that offer value unto themselves. (I'm > happy to help with that, since that's about all I'm good for around here. :-) > ) Enums were extensions of existing class types (is_object(Suit::Hearts) is true) rather than adding a whole separate type to the type system and don't need to support generics or contain anything other than an int/string. I don't think the choice of "epic" widely influenced the vote. Regards, Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
