Re: Re: Adding `final class Deque` to PHP

On Wed, Feb 2, 2022 at 6:59 AM tyson andre <tysonandre775@hotmail.com> wrote: > > 4. Returning $this makes code easier to write at some cost to readability > - Developers new to php or using Collections\Deque for the > first time > would not immediately know what the code they're reading is doing. > (less of a problem with a good IDE, typechecker, and a typed codebase, > but this isn't universal) > Having it return void, return $deque->push() would be > less common and > this would force the meaning to be clear. > > Developers might have several guesses/assumptions based on their > experience with other methods in php/elsewhere > > - It returns the new count (JavaScript Array.push, array_push) > - It returns $this (Ruby) > - It returns a lazy copy, like you'd wanted, not modifying the original > - It's returning void and the code in question is shorthand for `return > null`. > (Python, C++ > https://www.cplusplus.com/reference/vector/vector/push_back/ , > offsetSet > and spl push()/shift() methods) > > I'm not sure that I buy this as a point even. Returning an immutable Deque instance would be much more in line with modern PHP in general. A major complaint about my operator overloads RFC was how it impacted static analysis tools. I don't see how in one RFC we can say that creating work for static analysis tools is a blocking problem, and in a different RFC say that the ability to inspect the return values by the developer can't even be assumed. If we design one feature around the idea that a basic IDE may not even be used, but design a different feature around the idea that we want to minimize the impact to a third party tool that provides static analysis as part of workflow that's not even part of an IDE... well that seems like a very inconsistent approach to me. Either modern development tools are factored into the language design or they are not. This seems like a "having your cake and eating it too" situation. Jordan