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

This is only part of a thread. view whole thread
  110912
July 10, 2020 09:21 ocramius@gmail.com (Marco Pivetta)
Hi Nikita,

I kept my "NO" stance here, as per discussion in
https://externals.io/message/110004#110005, where I provided (in my
opinion) good/safe alternatives to arrays as input parameters.

The BC implications on this RFC still largely outweigh any advantages that
it brings, from my perspective.

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/


On Fri, Jul 10, 2020 at 10:42 AM Nikita Popov ppv@gmail.com> wrote:

> Hi internals, > > I have opened voting on the named arguments RFC: > https://wiki.php.net/rfc/named_params > > Voting will close on 2020-07-24. > > Regards, > Nikita >
  110913
July 10, 2020 10:11 rowan.collins@gmail.com (Rowan Tommins)
On Fri, 10 Jul 2020 at 10:21, Marco Pivetta <ocramius@gmail.com> wrote:

> I kept my "NO" stance here, as per discussion in > https://externals.io/message/110004#110005, where I provided (in my > opinion) good/safe alternatives to arrays as input parameters. >
For the record, I maintain my reaction from https://externals.io/message/110004#110010 that the example you give "cheats" by including a "fromArray" method which simply emulates named parameters, but without any assistance from the language would require a large amount of boiler-plate to do so. Would you be more open to a version of the feature that was opt-in at the definition site? Then your example could swap the hand-rolled documentation and validation in "fromArray" for a fully typed signature in "fromNamedParams", and the only compatibility promises would be ones already made by "fromArray" anyway. Regards, -- Rowan Tommins [IMSoP]
  110914
July 10, 2020 10:24 ocramius@gmail.com (Marco Pivetta)
Hey Rowan,
<http://ocramius.github.com/>


On Fri, Jul 10, 2020 at 12:11 PM Rowan Tommins collins@gmail.com>
wrote:

> On Fri, 10 Jul 2020 at 10:21, Marco Pivetta <ocramius@gmail.com> wrote: > > > I kept my "NO" stance here, as per discussion in > > https://externals.io/message/110004#110005, where I provided (in my > > opinion) good/safe alternatives to arrays as input parameters. > > > > > For the record, I maintain my reaction from > https://externals.io/message/110004#110010 that the example you give > "cheats" by including a "fromArray" method which simply emulates named > parameters, but without any assistance from the language would require a > large amount of boiler-plate to do so. >
If "array" is all you have to pass on as input, `fromArray` is what you can certainly use: that's useful when de-serializing from JSON input, DB, serialized state, etc. It certainly isn't meant to pass in the array via hand-crafted map: that's what other (additional) named ctors would be for.
> Would you be more open to a version of the feature that was opt-in at the > definition site?
Most certainly: as mentioned elsewhere (can't find it), having an attribute to demarcate whether an API can be used via named arguments would make the BC surface and BC promise explicit and clear.
> Then your example could swap the hand-rolled documentation > and validation in "fromArray" for a fully typed signature in > "fromNamedParams", and the only compatibility promises would be ones > already made by "fromArray" anyway.
The idea of multiple named ctors is to keep BC compatibility whilst allowing for multiple input formats that fit the current use-case. Data format changes? New ctor! Not a problem, unless internal invariants change massively. For example, in event-sourcing, you can likely never update past data (never, really!), so as you move forward, your de-serialization endpoints may be appropriately versioned: a `MyEvent::fromSerializedData(array)` must be designed to support all possible past representations of `MyEvent` (even if no longer complying with current domain rules), whereas `MyEvent::fromInput(PSR7Request)` can actively refuse invalid information (context matters a lot). ```php MyEvent::fromArray([ 'hand' => 'crafted', 'set' => 'of', 'parameters' => 'is', 'certainly' => 'not', 'how' => 'this', 'is' => supposed', 'to' => 'be', 'used', 'and' => 'causes', 'only' => 'trouble' ]); ``` The above is just complexity, and a lot of moving parts to keep track of. When coding with a defined data-set, you use `MyEvent::raise($with, $relevant, $typed, $information, $only);` I feel like I'm repeating myself though: this was already explained before. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
  110915
July 10, 2020 12:56 rowan.collins@gmail.com (Rowan Tommins)
On Fri, 10 Jul 2020 at 11:24, Marco Pivetta <ocramius@gmail.com> wrote:

> If "array" is all you have to pass on as input, `fromArray` is what you > can certainly use: that's useful when de-serializing from JSON input, DB, > serialized state, etc. > > It certainly isn't meant to pass in the array via hand-crafted map: that's > what other (additional) named ctors would be for. >
As I said in my previous response, I think this comes down to an unfortunate example - if what you actually have is an array, then yes, fromArray makes sense. One of the use cases for named parameters happens to look superficially similar to that, because it can be worked around by first creating an array, and then passing it somewhere. But the input you actually have is not an array, it is a set of variables from multiple sources, or a set of hard-coded parameters of different types that configure the functionality. One aspect I'd like to highlight is that named parameters aren't just useful for large numbers of individual parameters, but large numbers of _valid combinations_. For instance, with two optional parameters, you can quite easily have named methods to omit one or the other: function fromFoo($foo) function fromBar($bar) function fromFooAndBar($foo, $bar) You could even skip the third method by having optional parameters on one or both of the other two. But this list would increase exponentially; with only three parameters, you would need: function fromFoo($foo) function fromBar($bar) function fromBaz($baz) function fromFooAndBar($foo, $bar) function fromFooAndBaz($foo, $baz) function fromBarAndBaz($bar, $baz) function fromFooAndBarAndBaz($foo, $bar, $baz) Right now, there is no elegant way to combine these into one function signature. Named parameters are one solution, because they let you specify defaults for all parameters: function fromFooAndOrBarAndOrBaz($foo=42, $bar=true, $baz=[]) Another solution is parameter skipping, which was declined largely because people preferred named params: https://wiki.php.net/rfc/skipparams The only other alternative I know of is the builder pattern ($builder->withFoo($foo)->withBar($bar)->withBaz($baz)->build()), which at least makes the boilerplate scale linearly rather than exponentially, but is still going to require dozens of lines of code to achieve what named parameters can do with one. Regards, -- Rowan Tommins [IMSoP]
  110919
July 10, 2020 14:18 kontakt@beberlei.de (Benjamin Eberlei)
On Fri, Jul 10, 2020 at 11:21 AM Marco Pivetta <ocramius@gmail.com> wrote:

> Hi Nikita, > > I kept my "NO" stance here, as per discussion in > https://externals.io/message/110004#110005, where I provided (in my > opinion) good/safe alternatives to arrays as input parameters. >
> The BC implications on this RFC still largely outweigh any advantages that > it brings, from my perspective. >
Are there alternatives to named parameters? Of course. Are they as simple? Not really. 1. You can use an array, but array values cannot be typed, so you completly loose typing of the language. 2. You can use an object with builder pattern, but that requires a lot of code to write, and increases the mental capacity of understanding something for developers. 3. your example of an api to convert named params to a sequence is not discoverable, you don't know looking or using method A() that it comes with an additional NamedParamsA() helper. I see PHP as a language to get up and running quickly. So builder pattern is really more an advanced approach, should be used by not many use-cases. We have seen arrays of $options and $params to no end in framework and library APIs, with all their problems. So named params are a real improvement that feels like supporting "the php way(tm)". Lastly we need to consider internal APIs, which are usually about adding more parameters (htmlentities, json_decode, ...). These APIs are going to stay and benefit hugely from named params. Then the question becomes, do we rename parameters a lot? I doubt it's a large problem, and even then the variadics support makes it very easy to handle in a backwards compatible way. In addition libraries are always open to declare they don't consider named parameters as part of their API.
> Greets, > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > > > On Fri, Jul 10, 2020 at 10:42 AM Nikita Popov ppv@gmail.com> > wrote: > > > Hi internals, > > > > I have opened voting on the named arguments RFC: > > https://wiki.php.net/rfc/named_params > > > > Voting will close on 2020-07-24. > > > > Regards, > > Nikita > > >
  110930
July 10, 2020 22:34 cja987@gmail.com (Chuck Adams)
> Then the question becomes, do we rename parameters a lot? I doubt it's a > large problem, and even then the variadics support makes it very easy to > handle in a backwards compatible way. In addition libraries are always open > to declare they don't consider named parameters as part of their API.
Python supports the notion of "keyword-only arguments". If that was supported, and the renamed argument had a default, an API could rename parameters in a backward-compatible manner by introducing a kw-only arg with the same name. One could also consider an aliasing syntax such that more than one keyword could correspond to a named argument. Perhaps using an annotation? --c
  110962
July 12, 2020 10:24 php@manuelcanga.dev (Manuel Canga)
Hi,


 ---- En vie, 10 jul 2020 16:18:40 +0200 Benjamin Eberlei <kontakt@beberlei..de> escribió ----
 > On Fri, Jul 10, 2020 at 11:21 AM Marco Pivetta <ocramius@gmail.com> wrote:
 > 
 > > Hi Nikita,
 > >
 > > I kept my "NO" stance here, as per discussion in
 > > https://externals.io/message/110004#110005, where I provided (in my
 > > opinion) good/safe alternatives to arrays as input parameters.
 > >
 > 
 > > The BC implications on this RFC still largely outweigh any advantages that
 > > it brings, from my perspective.
 > >
 > 
 > Are there alternatives to named parameters? Of course. Are they as simple?
 > Not really.
 > 
 > 1. You can use an array, but array values cannot be typed, so you completly
 > loose typing of the language.
 > 2. You can use an object with builder pattern, but that requires a lot of
 > code to write, and increases the mental capacity of understanding something
 > for developers.
 > 3. your example of an api to convert named params to a sequence is not
 > discoverable, you don't know looking or using method A() that it comes with
 > an additional NamedParamsA() helper.
 > 


4. Other option is creating a  new function( not yet available in PHP ) like:

```
 array_check_scheme( array $array, array $scheme,  bool $forced = false  ): bool
```

( name of function can be better )

in order to check types in arrays. Then you could:

/**
  * @param array $args{name: string, surname: string, ?age: int}
 */
function my_function(  array $args ) {
   $scheme = ['name' => 'string', 'surname' => 'string', '?age' => 'int');
   $is_valid =  array_check_scheme( $args, $scheme );
}


my_function( ['name' = 'Nikita', 'surname' => 'Popov' ] );  //is_vaild = true
my_function( ['name' = 'Nikita'] );  //is_vaild = false
my_function( ['name' = 'Nikita'],  'age' => 10 );  //is_vaild = false

A function like this could be useful in other contexts as well.

Regards
--
Manuel Canga
  110963
July 12, 2020 12:19 rowan.collins@gmail.com (Rowan Tommins)
On 12 July 2020 11:24:50 BST, Manuel Canga <php@manuelcanga.dev> wrote:
>4. Other option is creating a new function( not yet available in PHP ) >like: > >``` >array_check_scheme( array $array, array $scheme, bool $forced = false >): bool >```
The problem with this, whether built in or not, is that you have to express everything with strings rather than keywords. That means, for instance, that invalid values in the definitions themselves will only error at run-time. The definitions also tend to get verbose pretty quickly. To make it concise and checked at compile-time, you need it to be a construct that pairs identifiers to types without first representing them as strings, e.g. to write `?string $foo = 'hello'` rather than `'foo' => ['type'=>'string', 'nullable'=>true, 'default'=>'hello']`. It turns out we already have a construct for doing that: function signatures. If the input is an actual array or object coming from "outside", you're probably going to want a more extensible validation system anyway. Those are really hard to design, and probably best left to userland where people can choose the tradeoffs they prefer. Regards, -- Rowan Tommins [IMSoP]
  110965
July 12, 2020 14:05 php@manuelcanga.dev (Manuel Canga)
Hi, Rowan,


 ---- En dom, 12 jul 2020 14:19:08 +0200 Rowan Tommins collins@gmail..com> escribió ----

 > The problem with this, whether built in or not, is that you have to express everything with strings rather than keywords. That means, for instance, that invalid values in the definitions themselves will only error at run-time. The definitions also tend to get verbose pretty quickly.
 > 
 > To make it concise and checked at compile-time, you need it to be a construct that pairs identifiers to types without first representing them as strings, e.g. to write `?string $foo = 'hello'` rather than `'foo' => ['type'=>'string', 'nullable'=>true, 'default'=>'hello']`. It turns out we already have a construct for doing that: function signatures.
 > 
 > If the input is an actual array or object coming from "outside", you're probably going to want a more extensible validation system anyway. Those are really hard to design, and probably best left to userland where people can choose the tradeoffs they prefer.
 > 
 > Regards,
 > 

I see. 

However, with named arguments you also have to implement changes in parser in order to can recognize named arguments. You also have to change behavior about default parameters. I don't know if this change affect to performance, maybe do. 

By the other hand, editor like PHPStorm has "Inlay Hints": 
https://www.jetbrains.com/help/rider/Inline_Parameter_Name_Hints.html

With a function which checks scheme, you also could use in other contexts, like  forms:

```
$scheme = ['name' => 'string', 'surname' => 'string', '?age' => 'int');
$is_valid = array_check_scheme( $_POST, $scheme ); 
```

You can use it even with JSON:

```
$request = json_decode( $request_json, true );
$scheme = ['name' => 'string', 'surname' => 'string', '?age' => 'int');
$is_valid = array_check_scheme( $request, $scheme ); 
```

 > e.g. to write `?string $foo = 'hello'` rather than `'foo' => ['type'=>'string', 'nullable'=>true, 'default'=>'hello']`

Maybe you don't need checked at compile-time. is it  slow?, securely, but you don't use in everywhere.

> you're probably going to want a more extensible validation system anyway.
Maybe, in that case, userland libraries have a starting point. With XML parsing is the same. PHP provides basic functionality and userland provide advanced. Regards -- Manuel Canga