Bug 1801966 Comment 3 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Matthew Gaudet (he/him) [:mgaudet] | Out Until January 3, 2023 from comment #2)
> A more robust, and useful for the web investment might be to instead fix Bug 1702038 and Bug 1759826, in general ensuring that private fields and methods have excellent and robust support through the debugger.

Unfortunately fixing those other bugs wouldn't really fix our issue, which is not being able to redefine private field values on the fly (in both manual and automated testing) the way we can for underscored values. It rules out sinon.JS which we currently use in automated tests to stub "pseudo-private" methods for example. So this is one of the things impeding adoption of private fields, which otherwise I would be excited to use. I imagine reassignment would be much more difficult to support than debugger access, but as you noted we already have bugs for the other issues
(In reply to Matthew Gaudet (he/him) [:mgaudet] | Out Until January 3, 2023 from comment #2)
> A more robust, and useful for the web investment might be to instead fix Bug 1702038 and Bug 1759826, in general ensuring that private fields and methods have excellent and robust support through the debugger.

Unfortunately fixing those other bugs wouldn't really fix our issue, which is not being able to redefine private field values on the fly (in both manual and automated testing) the way we can for underscored values. It rules out sinon.JS which we currently use in automated tests to stub "pseudo-private" methods for example. So this is one of the things (possibly the only thing?) impeding adoption of private fields, which otherwise I would be excited to use. I imagine reassignment would be much more difficult to support than debugger access, but as you noted we already have bugs for the other issues

Back to Bug 1801966 Comment 3