Re: [PHP-DEV] [VOTE] Interface Default Methods

On Jul 11, 2023, at 13:42, Larry Garfield wrote: > > On Tue, Jul 11, 2023, at 5:28 PM, Robert Landers wrote: >> >> IMHO, using a shared base class reflects the inheritance better >> because they are siblings (at least these appear to be logical >> siblings out of context, IMHO) and should look

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

Hi everyone, Apologies for not including context and responding to 40 emails all at once, I’m not at a computer (and won’t be for a few weeks). Given the comments I read in the thread, I wanted to make some key points that I hope will clarify my intent behind the proposal: * The primary

Re: [PHP-DEV] Request for couple memory optimized array improvements

Hi Riikka, > On Aug 31, 2020, at 14:13, Riikka Kalliomäki > wrote: > > A common pattern that I've seen that could dearly use PHP internal > optimization, if possible, would be: > > foreach (array_keys($array) as $key) { > } I have a draft RFC (https://wiki.php.net/rfc/foreach_void) and patch

Re: [PHP-DEV] [RFC] Guard statement

Pavel, On May 16, 2020, at 05:13, Pavel Patapau wrote: > > Hello everyone, > > I want to propose new syntax addition - guard statement, that executes code > only if expression equals false and must contain control-flow changing code, > and written a respective RFC: > >

Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax

Benas, > On May 15, 2020, at 04:33, Benas IML wrote: > > Hey, > > `guard` would be a keyword this means that all of the classes, interfaces and > traits named Guard would be illegal. Therefore Laravel's `Guard` interface > would be incompatible with PHP 8 which in turn means thousands of web

Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax

Benas, > On May 10, 2020, at 15:19, Benas IML wrote: > > Hello, > > I think that we SHOULD not introduce a new keyword (e. g. guard) since that > would be a "major major" backwards incompatibility. "Guard" is a really > generic > word and a great example of that is Laravel and their

Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax

Hi Ralph, > On May 10, 2020, at 11:49, Ralph Schindler wrote: > > Hi! > > > # Intro > > I am proposing what is a near completely syntactical addition (only change is > to language.y) to the language. The best terminology for this syntax is are: > `return if`, "return early", or "guard

Re: [PHP-DEV] [RFC] Named arguments

Hi Rowan, > On May 5, 2020, at 16:47, Rowan Tommins wrote: > > Hi John, > > On 05/05/2020 18:27, John Bafford wrote: >> I very much do like the idea of named parameters, but I do not like the >> specific proposal in the linked RFC at all. I think that treating

Re: [PHP-DEV] [RFC] Named arguments

On May 5, 2020, at 14:21, Nikita Popov wrote: > > Another is to allow specifying the public parameter name and the private > parameter variable name separately, as is possible in Swift. This would > allow changing "parameter" names arbitrarily, without breaking the public > API. This would be a

Re: [PHP-DEV] [RFC] Named arguments

Hi Nikita, > On May 5, 2020, at 09:51, Nikita Popov wrote: > > Hi internals, > > I've recently started a thread on resurrecting the named arguments proposal > (https://externals.io/message/109549), as this has come up tangentially in > some recent discussions around attributes and around

Re: [PHP-DEV] Typed array properties V2

> On Jan 24, 2020, at 14:27, Mike Schinkel wrote: > > Thus far we have discussed that implementation of type checking for arrays > would be too costly from a performance perspective and that there is no good > solution that is not extremely complicated to implement. > > Given that, can we

Re: [PHP-DEV] Typed array properties V2

> On Jan 19, 2020, at 19:53, Mike Schinkel wrote: > > P.S. There was also the mention by Levi Morrison that the type[] syntax was > a poor one because of ambiguity between (?int)[] or ?(int[]). I would argue > that the latter would likely occur orders of magnitude more often than the >

Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of Conduct

Chase, On Jan 22, 2016, at 13:15, Chase Peeler wrote: > > 1.) I think everyone already knows how to be an adult. The fact that > sometimes we don't act in a civil manner isn't because we don't have > something telling us what civil behavior entails. Putting it in writing

[PHP-DEV] PR #1723 - fix for crash in mysqli_connect

Hi all, Can someone take a look at this PR to fix a crash with mysqli_connect arising with a mysqlnd refactor in e81ecc80c in master from November: https://github.com/php/php-src/pull/1723 When attempting to mysqlI_connect(‘localhost’, ‘user’, ‘pass), the mysqlnd_conn_data::get_scheme

Re: [PHP-DEV] Back to the code (was Re: Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct))

Adam, Sascha, > On Jan 13, 2016, at 08:53, Adam Howard wrote: > > Well, I'm glad someone is in agreement. I really wish we'd get back to the > actual code. Because if not, I do think perhaps PHP Internals as outlived > the email format and should migrate to a forum

[PHP-DEV] Re: Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct)

Stas, On Jan 11, 2016, at 23:24, Stanislav Malyshev wrote: > > Hi! > >> This is yet another example of the toxic internals problem. >> Regardless of one's views on the CoC proposal, the conduct of >> php-internals as a whole has been reprehensible. > > What in your

Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct)

Sascha, > On Jan 12, 2016, at 11:17, Sascha Schumann > wrote: > > Hi John, > >> And it is *not* acceptable. > > May I ask who put you in charge to determine whether something is "acceptable" > or "reprehensible”? *I* avoid internals because *I* believe the

[PHP-DEV] Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct)

[Apologies for the re-post; I’m re-sending this with a new subject because it’s really not about the CoC RFC.] > On Jan 11, 2016, at 19:40, François Laupretre wrote: > > If we want to deal with the reasons why people avoid internals, the let's go > and analyze the problem

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

> On Jan 11, 2016, at 19:40, François Laupretre wrote: > > If we want to deal with the reasons why people avoid internals, the let's go > and analyze the problem first ? I will start asking whether we really want to > attract newcomers. The question may sound ridiculous but

Re: [PHP-DEV] Re: [RFC] array_key_(first|last|index) functions proposal

Hi Andrea, > On Jan 4, 2016, at 12:05, Andrea Faulds <a...@ajf.me> wrote: > > Hi John, > > John Bafford wrote: >> Happy New Year, everyone! >> >> I’d like to present the first new PHP RFC for this year, a proposal to add >> functions to ea

Re: [PHP-DEV] RFC Operator Overloading in Userspace

Hi Sara, On Jan 2, 2016, at 21:14, Sara Golemon wrote: > > Patricio Tarantino has asked me to help him propose Operator > Overloading in PHP 7.1 (based in part on my operator extension in > PECL). I think we can expose this to usespace as magic methods with > very little

Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team

> On Jan 1, 2016, at 15:20, Johannes Schlüter wrote: > > On Fri, 2016-01-01 at 13:28 -0500, Bishop Bettini wrote: >> Hi, and happy New Year! >> >> Now that the big push for PHP 7 is done, I'd like to revive earlier >> discussions >>

[PHP-DEV] [RFC] array_key_(first|last|index) functions proposal

Happy New Year, everyone! I’d like to present the first new PHP RFC for this year, a proposal to add functions to easily get the first, last, or an arbitrary key (and value) by index from an array, taking advantage of PHP’s property that arrays are ordered maps. RFC:

Re: [PHP-DEV] [RFC] array_key_(first|last|index) functions proposal

> On Jan 1, 2016, at 16:38, Bishop Bettini <bis...@php.net> wrote: > > On Fri, Jan 1, 2016 at 3:44 PM, John Bafford <jbaff...@zort.net> wrote: > Happy New Year, everyone! > > I’d like to present the first new PHP RFC for this year, a proposal to add > functi

[PHP-DEV] Re: [RFC] GitHub Pull Requests Triage Team

Hi Bishop, > On Jan 1, 2016, at 13:28, Bishop Bettini wrote: > > Hi, and happy New Year! > > Now that the big push for PHP 7 is done, I'd like to revive earlier > discussions on the GitHub PR triage team RFC. > Thanks for poking me about this. When I originally proposed the

Re: [PHP-DEV] [VOTE] Void Return Type RFC

There are two particular semantic advantages of void functions I’m not sure have been brought up. A function that always throws an exception can’t have a return value (and checking for one is also semantically and logically incorrect). Since such a function won’t ever return by normal means,

Re: [PHP-DEV] Let's discuss enums!

> On Sep 17, 2015, at 20:06, Bob Weinand <bobw...@hotmail.com> wrote: > >> Am 18.09.2015 um 01:52 schrieb John Bafford <jbaff...@zort.net>: >> >> If we’re bikeshedding, one feature I would really like to see, with >> typehinting, is warnings if all c

Re: [PHP-DEV] Let's discuss enums!

On Sep 17, 2015, at 19:16, Bob Weinand wrote: > >> Am 18.09.2015 um 01:06 schrieb Rowan Collins : >> >> This has come up in passing a few times recently, but I'm not sure there's >> ever been a dedicated discussion of it: would it be useful for PHP

Re: [PHP-DEV] Let's discuss enums!

> On Sep 17, 2015, at 20:15, Bob Weinand wrote: > >> Am 18.09.2015 um 01:56 schrieb Rowan Collins : >> >> On 18/09/2015 00:16, Marcio Almada wrote: >>> A kitten is working on thathttps://wiki.php.net/rfc/enum. Many points >>> on the linked RFC are

Re: [PHP-DEV] RFC: Nested enclosing returns

On Mar 21, 2015, at 10:17, Georges.L cont...@geolim4.com wrote: The main purpose of this RFC is *not* to improve the exception system of PHP but to improve the code logic/hierarchy. Hi php internals, After some long and deep research i finally decided to write my first RFC about a

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015, at 16:52, Stanislav Malyshev smalys...@gmail.com wrote: Hi! My proposal is something similar to Pythons slice, in PHP this would look like: $slided = $array[1:4] This will get the elements in positions 1,2,3,4. (1 through 4 inclusive), ignoring the actual key of the

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015, at 16:27, Alex Bowers bowersb...@gmail.com wrote: On 20 March 2015 at 20:10, Sean Coates s...@seancoates.com wrote: That’s no different than `@` being invalid because it’s already in use. The syntax would be [*from:to], which would currently throw a parse error (since

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015, at 14:17, Rowan Collins rowan.coll...@gmail.com wrote: It doesn't work *with that syntax*, because -1 is a valid key, just as $thing[0] can't mean first value of array because it already means value with key 0. That's why I propose a new syntax such as $thing[@0],

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015, at 16:10, Sean Coates s...@seancoates.com wrote: I posted four suggestions earlier, They were: @ * ^ My favourites are the asterisk or caret. That’s no different than `@` being invalid because it’s already in use. $ php -a Interactive shell php

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015, at 17:27, Stanislav Malyshev smalys...@gmail.com wrote: Hi! I provided an array_key_first() implementation awhile ago that was first shot down because “too many array_* functions”, and then later ignored because I didn’t want to go through the RFC process just to add a

Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team

On Oct 31, 2014, at 12:10, Andrea Faulds a...@ajf.me wrote: On 30 Oct 2014, at 21:57, John Bafford jbaff...@zort.net wrote: I would like to propose the creation of a team to triage the pull requests on GitHub, to help ensure that the pull requests are handled in a timely manner. I am

Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team

On Nov 1, 2014, at 10:27, Xinchen Hui larue...@php.net wrote: Hey: On Sat, Nov 1, 2014 at 7:53 PM, Pierre Joye pierre@gmail.com wrote: Hi, On Oct 31, 2014 4:57 AM, John Bafford jbaff...@zort.net wrote: Hi, I would like to propose the creation of a team to triage the pull

Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team

On Nov 1, 2014, at 08:28, Rowan Collins rowan.coll...@gmail.com wrote: On 1 November 2014 11:53:11 GMT, Pierre Joye pierre@gmail.com wrote: Hi, On Oct 31, 2014 4:57 AM, John Bafford jbaff...@zort.net wrote: Hi, I would like to propose the creation of a team to triage the pull

Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team

On Oct 31, 2014, at 12:15, Ferenc Kovacs tyr...@gmail.com wrote: On Fri, Oct 31, 2014 at 3:13 PM, Florian Anderiasch m...@anderiasch.de wrote: On 31.10.2014 09:58, Peter Cowburn wrote: On 30 October 2014 21:57, John Bafford jbaff...@zort.net wrote: Hi, I would like to propose

[PHP-DEV] [RFC] GitHub Pull Requests Triage Team

Hi, I would like to propose the creation of a team to triage the pull requests on GitHub, to help ensure that the pull requests are handled in a timely manner. I am also volunteering to lead such a team, should the RFC be approved. https://wiki.php.net/rfc/github-pr PHP’s GitHub repository

[PHP-DEV] VCS Account Request: jbafford

I would like access to edit the wiki and submit RFCs. Thanks, -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP class files without ?php at the top

in. -John -- John Bafford http://bafford.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP class files without ?php at the top

developers who liked it would make autoloaders available that honored it, freeing end-user developers from thinking about it. It becomes self-contained, and people who are writing old-school .php standalone scripts or pages are entirely unaffected. On Sat, Apr 7, 2012 at 9:50 AM, John Bafford

Re: [PHP-DEV] PHP class files without ?php at the top

line, corresponds with begin_code (also command line)) args (also command line) Any PHP_INI_ALL directives John Crenshaw Priacta, Inc. -John -- John Bafford http://bafford.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Add E_STRICT when defining a required function parameter after an optional parameter

not immediately break code that (until now) worked without warning. Thoughts/comments? -John -- John Bafford http://bafford.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Add E_STRICT when defining a required function parameter after an optional parameter

with this solution than my first. It might also be possible to get rid of zend_arg_info.optional, but I'd need to know how/if it's possible to access the relevant oplines for the rest of the function's parameters. -John -- John Bafford http://bafford.com/ -- PHP Internals - PHP Runtime

[PHP-DEV] [PATCH] New functions: array_key_index(), array_first(), array_last()

of the array: NULL string(5) first -- John Bafford [EMAIL PROTECTED] http://www.dshadow.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php