Re: [RFC] Named arguments

From: 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]

« previous php.internals (#110010) next »