@tommythorsen, exposing the internal state might be good, but we should consider them on a case-by-case basis (in terms of developer value). Specifically, if the internal slots just hold the values that were passed as arguments to the PaymentRequest constructor, then developers can just get at those (original) references: they passed them in, so they know what they are.
```JS
// These are all accessible
const methodData = {...};
const details = {...};
const options = {...};
// These are copied... but basically reflect the above
const request = new PaymentRequest(methodData, details, options);
```
Also, given that we now have two shipping implementations (and a third one on the way in Gecko), we probably don't want to make these kinds of API additions for v1 unless they solve some fairly compelling use cases.
--
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/browser-payment-api/issues/393#issuecomment-272750281
Received on Monday, 16 January 2017 00:30:00 UTC