Re: [webpayments] PROPOSAL: The PaymentRequest object SHOULD NOT expose internal state information to the developer. Any design that requires developers to manage or understand the request state is a compromise in the API design that should be avoided where possible. (#64)

> But it doesn't follow that exposing the state does require depending on it.

My concern is that by exposing internal state, Web developers will start depending on it and it's been made clear, at least in this case, that you can't depend on that variable (due to the aforementioned race conditions).

> But it is very useful from an implementation perspective (try writing a polyfill without it)

The specs are supposed to expose the *public-facing bits*, not "debugging info". We're all in agreement that the API implementation will most likely need to track state to some degree, polyfill implementations included.

The proposal in this thread is attempting to say: "Yes, track state internally, but don't expose the internal implementation bits to Web developers because they'll likely think they can depend on it (which they can't due to race conditions)."

An alternative is to stick the "state" bits in a "debug" variable, but I don't really like that approach either because I don't know of any other (successful) API that does that.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/64#issuecomment-180783060