On Tue, 5 May 2020 at 16:56, Marco Pivetta <ocram...@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]
