Re: [PHP-DEV] [RESULT] Re: [PHP-DEV] [VOTE] Round two, PHP 8.0 RM

> On May 5, 2020, at 12:19, Derick Rethans wrote: > > Hi all, > > the vote for the second release manager has been concluded. At a nail > biting 18 vs 19, Gabriel Caruso is chosen! Congrats. Congratulations, Gabriel, and best of luck! Cheers, Ben signature.asc Description: Message signed

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

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 named parameters simply as syntactic sugar is not a good approach. If we're going to add named

Re: [PHP-DEV] Re: [RFC] Constructor Property Promotion

On Tue, May 5, 2020, at 7:35 AM, Nikita Popov wrote: > Performing validation when the getAttributes() call is performed does sound > reasonable to me. We can also add a class flag to perform this validation > only once (if it is successful), so the cost doesn't have to be paid by > every single

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

> On May 5, 2020, at 2:37 PM, Lynn wrote: > > If I understand this correctly, something like this could be done? > > ``` > // current version, argument name = "firstArgument" > function example(string $firstArgument) {} > // name changes, bc can be kept, argument name = "firstArgument" and >

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

On May 5, 2020, at 2:33 PM, Marco Pivetta wrote: > > On Tue, May 5, 2020 at 8:22 PM Nikita Popov wrote: > >> subprocess.run(args, *, stdin=None, input=None, stdout=None, >> stderr=None, capture_output=False, shell=False, cwd=None, timeout=None, >> check=False, encoding=None, errors=None,

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

On Tue, May 5, 2020 at 8:22 PM Nikita Popov wrote: > Anyway. Your point that named arguments expand the API surface has been > acknowledged. I don't think this issue is really avoidable, it's a rather > fundamental trade-off of named parameters. I do think you're a bit quick in > jumping to

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

On Tue, May 5, 2020 at 8:22 PM Nikita Popov wrote: > Builders and withers? Those are not, intrinsically, good code. They are > workarounds for lack of good object initialization support. I should not > have to implement a large amount of builder boilerplate to make the > construction of simple

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

On Tue, May 5, 2020 at 7:19 PM Marco Pivetta wrote: > Hey Theodore, > > > > On Tue, May 5, 2020 at 6:59 PM Theodore Brown > wrote: > >> On Tue, May 5, 2020 at 9:11 AM Marco Pivetta wrote: >> >> > As mentioned some days ago, I see named parameters as an added >> liability, >> > rather than

Re: [PHP-DEV] [RESULT] Re: [PHP-DEV] [VOTE] Round two, PHP 8.0 RM

On Tue, May 5, 2020 at 12:19 PM Derick Rethans wrote: > the vote for the second release manager has been concluded. At a nail > biting 18 vs 19, Gabriel Caruso is chosen! Congrats. > > Congratulations, Gabriel! I assume you're already familiar with

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

On Tue, 5 May 2020 at 18:19, Marco Pivetta wrote: > > I do in fact consider the `ParamNode` example in that API to be a bad > candidate for named parameters, since I'd make all of the arguments in that > signature required anyway: defaults aren't meaningful anyway, as the AST > library where it

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

> Marco Pivetta hat am 5. Mai 2020 um 16:11 geschrieben: > > Hey Nikita, > On Tue, May 5, 2020 at 3:51 PM 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

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

[PHP-DEV] [RESULT] Re: [PHP-DEV] [VOTE] Round two, PHP 8.0 RM

Hi all, the vote for the second release manager has been concluded. At a nail biting 18 vs 19, Gabriel Caruso is chosen! Congrats. cheers, Derick On Wed, 22 Apr 2020, Derick Rethans wrote: > Hi, > > as I mentioned, the first STV round ran into a tie, so there is a > current run-off between

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

Hey Theodore, On Tue, May 5, 2020 at 6:59 PM Theodore Brown wrote: > On Tue, May 5, 2020 at 9:11 AM Marco Pivetta wrote: > > > As mentioned some days ago, I see named parameters as an added liability, > > rather than values. > > The rationale of my negativity

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

On Tue, May 5, 2020 at 9:11 AM Marco Pivetta wrote: > As mentioned some days ago, I see named parameters as an added liability, > rather than values. > The rationale of my negativity around the topic being that a diff like > following is now to be considered a BC break: > > ```diff > -function

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

On Tue, 5 May 2020 at 16:56, Marco Pivetta wrote: > > Sorry, but no: you provide multiple constructors, each with a limited set > of arguments, each guaranteeing constraints that depend on context. > > For instance, a `fromArray()` may check for key existence, while > `fromJson()` may use a

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

Hey Benjamin, On Tue, May 5, 2020 at 5:44 PM Benjamin Eberlei wrote: > I see the PHP internal API as the main benefactor of this feature over > userland code imho. Internals realistically couldn't get "smaller APIs" > without adding many new functions instead, for example htmlspecialchars. >

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

On Tue, May 5, 2020 at 4:11 PM Marco Pivetta wrote: > Hey Nikita, > > On Tue, May 5, 2020 at 3:51 PM 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

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

Hey Larry, On Tue, May 5, 2020 at 5:29 PM Larry Garfield wrote: > The biggest use case I see is, as discussed previously, value object > constructors. "Pass an entirely untyped and undocumentable array of > parameters" is not an sufficient userland solution in my mind, but is the > only

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

On Tue, May 5, 2020, at 9:11 AM, Marco Pivetta wrote: > Hey Nikita, > > On Tue, May 5, 2020 at 3:51 PM 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

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

Hey Nikita, On Tue, May 5, 2020 at 3:51 PM 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

[PHP-DEV] [RFC] Named arguments

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 object ergonomics. I've now updated the old proposal on this topic, and moved

Re: [PHP-DEV] Re: [RFC] Constructor Property Promotion

On Wed, Apr 29, 2020 at 11:27 AM Benjamin Eberlei wrote: > > > On Wed, Apr 29, 2020 at 11:07 AM Nikita Popov > wrote: > >> On Wed, Apr 29, 2020 at 10:56 AM Benjamin Eberlei >> wrote: >> >>> >>> >>> On Wed, Apr 29, 2020 at 9:47 AM Nicolas Grekas < >>> nicolas.grekas+...@gmail.com> wrote: >>>

[PHP-DEV] Re: [VOTE] Voting opens for str_starts_with and ends_with function

Hello, I closed voting on the RFC page today and updated the main RFC page. The RFC was approved by 51 votes to 4. I assume the next step is to get the github PR approved and merged. Thanks, Will On 2020-04-19 22:58, w...@wkhudgins.info wrote: Hello, I have opened voting for the

[PHP-DEV] Breaking up php_error_cb/zend_error_cb to improve API for extensions

Heyo, I am experimenting with changes to break up the central error handling code into better manageable pieces for a while now. The idea was already voted positively upon in this RFC https://wiki.php.net/rfc/improved_error_callback_mechanism by Patrick five years ago, but it was never

Re: [PHP-DEV] Deprecating uniqid()

On Tue, 5 May 2020 at 10:26, Rowan Tommins wrote: > On Tue, 5 May 2020 at 08:52, Peter Bowyer > wrote: > > > > > On Tue, 5 May 2020 at 07:38, Niklas Keller wrote: > > > >> Rowan Tommins schrieb am Mo., 4. Mai 2020, > >> 10:59: > >> > Although the name sounds similar, I don't think UUID would

Re: [PHP-DEV] Deprecating uniqid()

On Tue, 5 May 2020 at 08:52, Peter Bowyer wrote: > > On Tue, 5 May 2020 at 07:38, Niklas Keller wrote: > >> Rowan Tommins schrieb am Mo., 4. Mai 2020, >> 10:59: >> > Although the name sounds similar, I don't think UUID would be a good >> > replacement for uniqid(). In my experience, it's used

Re: [PHP-DEV] Deprecating uniqid()

On Tue, 5 May 2020 at 07:38, Niklas Keller wrote: > Rowan Tommins schrieb am Mo., 4. Mai 2020, > 10:59: > > Although the name sounds similar, I don't think UUID would be a good > > replacement for uniqid(). In my experience, it's used for things like > > generating ID attributes for HTML

Re: [PHP-DEV] Deprecating uniqid()

Rowan Tommins schrieb am Mo., 4. Mai 2020, 10:59: > On Mon, 4 May 2020 at 06:27, Andreas Heigl wrote: > > > > > As replacement I could think of showing people the way to UUIDs. > > > > > Although the name sounds similar, I don't think UUID would be a good > replacement for uniqid(). In my