Re: [w3c/payment-request] Extensibility of PaymentResponse.complete(result) (#817)

@rsolomakhin said:

> For the sake of feature detection, may I also suggest to use a different name for the method that sends over an object instead of enum?

I worry that makes the API for a developer a little confusing. i.e. When do I call complete and when do I call confirm? That said, I'm not sure how else you could provide a feature detectable difference.

@marcoscaceres said:

> to keep things backwards compatible, we could add a second argument.

I think my proposal is already backwards compatible (at least from the perspective of a developer using the API). I've proposed changing the type of the argument from `enum` to `object` which I had assumed is non-breaking for any javascript that is calling the API but I don't know enough about the IDL and JS relationship.

> The underly question here is if PaymentComplete enum values apply to all transactions and it that needs to be extended beyond the three current values?

I think it would be a mistake to assume we can design anything that "applies to all transactions". Even if that's true now it'll probably not be true for long.

I could live with the two-argument solution, my only reservation is that this allows for ambiguous input (e.g. enum: `success`, detail: something that suggests failure).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/817#issuecomment-455512664