[VOTE] Named arguments

Hey Rowan,
http://ocramius.github.com/

On Fri, Jul 10, 2020 at 12:11 PM Rowan Tommins rowan.collins@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).

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/

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

Hi,

---- En vie, 10 jul 2020 16:18:40 +0200 Benjamin Eberlei kontakt@beberlei.de escribió ----

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