Hi Jordan, > > 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.
There's a difference between 1. https://externals.io/message/116767#116768 One contributor to a static analyzer thinking it would not be worth the complexity it adds to support in static analysis (and making type inference either vaguer or inaccurate for operands with a type `mixed` *more frequently*) Debuggability seemed to be their bigger objection. As a maintainer of a different static analysis tool, I'd disagree with that being a blocker, though. It'd be inconvenient to implement but would get implemented. 2. Aiming to "cater to the skill levels and platforms of a wide range of users", considering benefits/drawbacks to both groups of users (with/without static analyzers). (https://wiki.php.net/rfc/template) I don't think I'd have much success in an RFC adding immutable datastructures, though. Though interestingly, they do seem possible to implement with better performance (https://en.wikipedia.org/wiki/Big_O_notation) than I'd have expected. Google searching mentioned Relaxed Radix Binary Trees, an immutable datastructure surprisingly claiming performance near arrays in most operations. https://hypirion.com/musings/thesis https://github.com/hyPiRion/c-rrb Aside: An Immutable Map/Set would probably have a stronger argument than immutable sequeunces/deques/linked lists (arrays support copy on write already so the original array is immutable, but arbitrary keys are something arrays don't support), but voters that didn't see a use case for immutables in core might be unconvinced. > 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. The language design is decided by what the set of voters that voted on a particular RFC would approve with a 2/3 majority. Voters have a wide variety of backgrounds and projects/libraries that they work on, and RFC authors have to guess at what those backgrounds are and what functionality would be accepted, or why similar past RFCs were really objected. The preferences, backgrounds, and paradigms preferred by voters vary and I likely won't know what those preferences are or how many voters there would be until a vote is started. (e.g. frequency of writing new code vs maintaining existing codebases vs working with third party libraries) (e.g. **I won't know if anyone is strongly against fluent interfaces, or specifically strongly against adopting fluent interfaces in an ad-hoc way, without a policy RFC** such as the one that passed for namespaces https://wiki.php.net/rfc/namespaces_in_bundled_extensions) The fact that the closest look at the design/implementation for complex RFCs sometimes only happens shortly before/after the start of a vote is also inconvenient for authors, but hard to change with a volunteer-based process. This has downsides for current or future RFC authors, but I don't have any productive ideas for how to change the process that wouldn't split development or be burdensome to voters. (and would actually be accepted) Regards, Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
