Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110914
MIME-Version: 1.0
References: <CAF+90c_DPYqzOH1TU2mrG7cjh87RNXEzMx3hAAeDRfbTPpGVvw@mail.gmail.com>
 <CADyq6sL16QTzCe5=60oVDfLkAd8s_udBkKQPbc6_8MtRW_+rYw@mail.gmail.com> <CALKiJKquS_kqBuBSht0X2Q_33wFSYodWKfBSYp8k1yvk4qh41A@mail.gmail.com>
In-Reply-To: <CALKiJKquS_kqBuBSht0X2Q_33wFSYodWKfBSYp8k1yvk4qh41A@mail.gmail.com>
Date: Fri, 10 Jul 2020 12:24:08 +0200
Message-ID: <CADyq6sL9vwPChhxvju7vrVw7BNF0KYbuEJX8Yg0LRirW63WLCQ@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000077843705aa13be0b"
Subject: Re: [PHP-DEV] [VOTE] Named arguments
From: ocramius@gmail.com (Marco Pivetta)

--00000000000077843705aa13be0b
Content-Type: text/plain; charset="UTF-8"

Hey Rowan,
<http://ocramius.github.com/>


On Fri, Jul 10, 2020 at 12:11 PM Rowan Tommins <rowan.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/

--00000000000077843705aa13be0b--