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

Hey Nikita, This is a bit late response but ah, who cares ;-) I suppose that for consistency with named params, we should also make `declare` compatible with this syntax. So for example, `declare(strict_types: 1);` would be the same as `declare(strict_types=1)`. This would also make much more

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

On Fri, Jun 5, 2020 at 3:40 PM Nikita Popov wrote: > On Fri, Jun 5, 2020 at 12:45 PM Christian Schneider > wrote: > >> Am 05.05.2020 um 15:51 schrieb Nikita Popov : >> > \I've now updated the old proposal on this topic, and moved it back >> under >> > discussion:

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

On Fri, Jun 5, 2020 at 12:45 PM Christian Schneider wrote: > Am 05.05.2020 um 15:51 schrieb Nikita Popov : > > \I've now updated the old proposal on this topic, and moved it back under > > discussion: https://wiki.php.net/rfc/named_params > > First of all I really like this approach to Named

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

Am 05.05.2020 um 15:51 schrieb Nikita Popov : > \I've now updated the old proposal on this topic, and moved it back under > discussion: https://wiki.php.net/rfc/named_params First of all I really like this approach to Named Parameters: It seems to fit well with the rest of PHP. Note: I'm using

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

Hi John, On 6 May 2020 19:18:41 BST, John Bafford wrote: You're not wrong here, but, I think that's an (critical) implementation detail of Objective-C and Smalltalk that is not relevant here. Also, Swift does not use selectors or message passing, unless either interoperating with ObjC classes,

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 named >> parameters simply as

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

On Tue, May 5, 2020 at 8:38 PM Lynn wrote: > > > 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

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] [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] [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

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