Hey Rowan, <http://ocramius.github.com/>
On Fri, Jul 10, 2020 at 12:11 PM Rowan Tommins <rowan.coll...@gmail.com> wrote: > On Fri, 10 Jul 2020 at 10:21, Marco Pivetta <ocram...@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/
