Re: [RFC] Named arguments
| From: | Rowan Tommins | Date: | Tue, 05 May 2020 16:27:52 +0000 |
| Subject: | Re: [RFC] Named arguments | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-110010@lists.php.net to get a copy of this message | ||
On Tue, 5 May 2020 at 16:56, Marco Pivetta <ocramius@gmail.com> wrote:
>
> Sorry, but no: you provide multiple constructors, each with a limited set
> of arguments, each guaranteeing constraints that depend on context.
>
> For instance, a
fromArray() may check for key existence, while
> fromJson() may use a JSON-Schema definition to check that all
> is as
> required, and fromXmlPayload() may apply an XSD validator, and
> so on...
>
Maybe it's just an unfortunate choice of example, but my reaction was the
same as Benjamin's: "fromArray" doesn't look like "a named constructor with
a limited set of arguments", it looks like a hack used to emulate named
parameters by setting them as keys in an array which then has to be
manually documented and validated.
The only fully generic alternative I know of that can be properly checked
by static analysis is some kind of builder API:
myHorribleLegacyAndOrganicallyGrownApi(
...(new MyInfiniteSequenceOfParametersBuilder)
->setFoo($foo)
->setBar($bar)
// ... etc
->toSequentialParameters()
);
I do sympathise with the problems of making parameter names part of the
compatibility contract, and until recently have always argued it should be
opt-in at the call-site. I've been somewhat won round to the idea that that
leaves the migration too painfully slow.
Regards,
--
Rowan Tommins
[IMSoP]