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

[Rowan Tommins]

On Fri, 10 Jul 2020 at 09:42, Nikita Popov  wrote:

> Hi internals,
>
> I have opened voting on the named arguments RFC:
> https://wiki.php.net/rfc/named_params
>



I see this vote is currently running close to the super-majority threshold.

To those of you whose main concern is the need for libraries to consider
backwards compatibility of parameter names, I wanted to point to Symfony's
"compatibility promise" [1] and in particular the general disclaimer on
anything marked "@internal". There will always be ways to use a library
which the author didn't intend; it would be quite reasonable for a library
author to say "I do not promise that calling these methods with named
parameters will not break".

[1] https://symfony.com/doc/current/contributing/code/bc.html

To those of you who feel there are better ways to design APIs to avoid ever
needing to skip parameters, it would be great to see some ideas to make
those alternatives easier. For instance, if you think parameter objects
plus the builder pattern is the right way to go, how can we reduce the
boilerplate currently required to define the builder class?

Regards,
-- 
Rowan Tommins
[IMSoP]

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

[Manuel Canga]

Hi, Rowan,


  En dom, 12 jul 2020 14:19:08 +0200 Rowan Tommins 
 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Rowan Tommins]

On 12 July 2020 11:24:50 BST, Manuel Canga  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]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Manuel Canga]

Hi,


  En vie, 10 jul 2020 16:18:40 +0200 Benjamin Eberlei  
escribió 
 > On Fri, Jul 10, 2020 at 11:21 AM Marco Pivetta  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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Levi Morrison]

On Fri, Jul 10, 2020 at 2:42 AM Nikita Popov  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

I have decided to vote yes, though I'm a bit skeptical on a few
points. Notably this one:

> Functions declared as variadic using the ...$args syntax will also collect 
> unknown named arguments into $args.

Hopefully I'm just wrong about this being an issue and here's to
hoping it doesn't bite us later.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Benjamin Eberlei]

On Fri, Jul 10, 2020 at 11:21 AM Marco Pivetta  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 
> 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
> >
>

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

[Rowan Tommins]

On Fri, 10 Jul 2020 at 11:24, Marco Pivetta  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]

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

[Marco Pivetta]

Hey Rowan,



On Fri, Jul 10, 2020 at 12:11 PM Rowan Tommins 
wrote:

> On Fri, 10 Jul 2020 at 10:21, Marco Pivetta  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/

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

[Rowan Tommins]

On Fri, 10 Jul 2020 at 10:21, Marco Pivetta  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]

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

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

[PHP-DEV] [VOTE] Named arguments

[Nikita Popov]

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