Hi Levi Morrison, > I mean that there isn't a way to provide a custom way to compare for > equality. One way to accomplish this is to have a signature like: > > function contains(T $value, ?callable(T, T):bool $comparator = null): bool > > The same goes for `indexOf`.
It'd make much more sense to have `->any(static fn($other): bool => $comparator($value, $other)): ?:int` Overloading contains to do two different things (identity check or test the result of a callable) seems like it's unintuitive to users. Since there is plenty of time to add more functionality, and I still haven't created the extended iterable library proposal, this currently only adds operations that are significantly more efficient inside the Vector (or have a return type of Vector) rather than going through the generic Iterator methods. > > > - I don't know what `setSize(int $size)` does. What does it do if the > > > current size is less than `$size`? What about if its current size is > > > greater? I suspect this is about capacity, not size, but without docs > > > I am just guessing. > > > > It's the same behavior as > > https://www.php.net/manual/en/splfixedarray.setsize.php . It's about size, > > not capacity. > > > > > Change the size of an array to the new size of size. > > > If size is less than the current array size, any values after the new > > > size will be discarded. > > > If size is greater than the current array size, the array will be padded > > > with null values. > > > > I'd planned to add phpdoc documentation and examples before starting a vote > > to document the behavior and thrown exceptions of the proposed methods. > > I would rather see multiple methods like: > function truncateTo(int $size) > function padEnd(int $length, $value) // allows more than just null > function padBeginning(int $length, $value) I'd consider this unfriendly to users (and personally consider it a poor design) if we start with 3 or 4 different ways to change the size of the Vector. (Especially if English is a second language) A wide variety of programming languages such as Java, Rust, C++, etc. all use resize rather than truncateTo/padEnd, after what I assume is considerable discussion among language design experts in those languages. In the vast majority of cases, users know the exact size they want and don't care about the mechanism to set that. (And if the size is set larger or smaller in an `if{...}else{...}`, the existence of setSize is still needed. Or if the user intends to reuse the allocated memory while overwriting all values.) - Diverging from what end users are familiar with (without a strong reason to) would also make it harder to start using `Vector`. I'd considered using a signature of `setSize(int $size, mixed $value = null)` to allow using something other than null but decided to leave that to a followup proposal if it passed. For now, I'd omitted ways to add to the start of the array because the linear time taken would be potentially objectionable, if people didn't imagine using it themselves or thought it'd be more appropriate for end users to use a Deque. > And one or more for increasing/ensuring capacity without changing size. setCapacity seems useful to me for reserving exactly the amount of memory needed when the final size was known (e.g. setCapacity(2) to avoid over-allocating) but I was waiting to see if anyone else wanted that. Thanks, Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
