Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64)

> You could perhaps require that things work for the "plain 'ol Javascript Object (POJSO)" case, but trying to rule out code in the object is quixotic.

Agreed that in particular is quixotic. Let me think for a bit and try to rephrase.

The general point is "Let's not make this browser API more complicated than it needs to be", and when focusing specifically on just the PaymentRequest object, it feels more complicated than it needs to be because: 1) it requires the developer to be keenly aware of state changes, and 2) it hangs functionality off of the PaymentRequest object that, arguably, complicates how a developer has to manage it.

Clearly if we have use cases that need state, then we need to manage state. The assertion is to try to avoid making developers manage that state in the first place and have the implementations do it in the background, if possible. The Web Payments Browser API (from the Web Payments CG) proposes one such way to do that. In that proposal all objects passed to navigator.payments.* are: 1) plain 'ol Javascript Objects,  and 2) no state information needs to be exposed to the developer.

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