# Make `always true` SPL methods return void - Thread: https://externals.io/message/110615 - Original archive: https://news-web.php.net/php.internals/110615 - Started by Gabriel Caruso on 2020-06-17T02:00:09+00:00 - Messages: 5 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #110615 — Gabriel Caruso — 2020-06-17T02:00:09+00:00 URL: https://externals.io/message/110615#110615 Hello, internals, Inspired by the bug report #75958 (http://bugs.php.net/75958), I'd like to change the return type of some SPL methods that are always returning `true` and only `true`. These "always `true`" returns make no sense, as you can't wrap it in an `if`/`else` to catch something that happened, so changing it to `void` and just invoke these methods sounds reasonable to me. You can find the PR, with some discussion already, at https://github.com/php/php-src/pull/5314. Can I proceed with these changes, or should I create an RFC for that? -- Gabriel Caruso --- ## #110627 — Dan Ackroyd — 2020-06-17T10:17:42+00:00 URL: https://externals.io/message/110615#110627 · In reply to: #110615 > > so changing it to `void` and > just invoke these methods sounds reasonable to me. What's the benefit of doing the change? There will almost certainly be some code somewhere that would be broken by changing it, so it needs some benefit for doing it. I strongly suspect just updating the documentation to be correct, and then leaving the code behaving as it has been for the past decade or so, would be a better strategy. cheers Dan Ack --- ## #110678 — Jesse Rushlow — 2020-06-19T03:17:06+00:00 URL: https://externals.io/message/110615#110678 · In reply to: #110627 * Disclaimer - I have not thoroughly reviewed the bug report or PR mentioned. From a PHP developers perspective, if I was calling a method that returned true. I would automatically assume that the method is capable of returning the inverse of that as well. I see Dan's point of "let sleeping dogs lie" per say and just adjust the docs. But I'm leaning more towards if a method can't return false & true, then it should return something else or void. Thanks Jesse Rushlow > On Wed, 17 Jun 2020 at 03:00, Gabriel Caruso > wrote: > > […] > > What's the benefit of doing the change? > > There will almost certainly be some code somewhere that would be > broken by changing it, so it needs some benefit for doing it. > > I strongly suspect just updating the documentation to be correct, and > then leaving the code behaving as it has been for the past decade or > so, would be a better strategy. > > cheers > Dan > Ack > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #110685 — Marco Pivetta — 2020-06-19T13:42:29+00:00 URL: https://externals.io/message/110615#110685 · In reply to: #110627 Hey Dan, Gabriel, > On Wed, 17 Jun 2020 at 03:00, Gabriel Caruso > wrote: > > […] > > What's the benefit of doing the change? > > There will almost certainly be some code somewhere that would be > broken by changing it, so it needs some benefit for doing it. > > I strongly suspect just updating the documentation to be correct, and > then leaving the code behaving as it has been for the past decade or > so, would be a better strategy. > Perhaps this is a good chance to fix the quirks around the `false` type, as well as introducing the `true` type (and using it for these specific functions)? See https://3v4l.org/ZnWmc/rfc#output See https://3v4l.org/MqsvC/rfc#output Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ --- ## #110690 — johannes@schlueters.de — 2020-06-21T01:15:14+00:00 URL: https://externals.io/message/110615#110690 · In reply to: #110678 > * Disclaimer - I have not thoroughly reviewed the bug report or PR > mentioned. > > From a PHP developers perspective, if I was calling a method that > returned true. I would automatically assume that the method is > capable of returning the inverse of that as well. The fact that it doesn't today, might change tomorrow. If it now returns true this can be changed with less BC issues later. Also returning true allows chaining with `&&`, which void wont't. Also to the specific case: The specific case is about this: $test = new \SplStack(); var_dump( $test->push(1)); Assume we add a SplLimitedStack with a ore-defined size. There push might return false if the stack is full. By having "all" push() methods following the same pattern, generic code can work on either the same way. Thus looking at a single method isn't good for a design, but one should look at a class of types. (and then it might be a decision that push always returns void and errors should be reported via exception) Just to point out that there is a bit more than "oh, this always returns true" Also another side note: We have echo and print. print purposely always returns true for being usable in expression chains. johannes