In general, I'm pretty against this kind of monkey-patching if it's made available to out-of-tree consumers. We should learn our lesson from XPCOM and recognize what a royal PITA it can be when extensions start to depend on implementation details. Allowing something to be modified/overridden by embeddors should be an explicit decision, rather than the other-way around.
bholley On Tue, Oct 8, 2013 at 1:16 PM, David Rajchenbach-Teller < dtel...@mozilla.com> wrote: > A (not very) long time ago, our extension model was based on XPCOM – if > you didn't like a component, you could just replace it in an add-on. > These days, we have shifted to providing JavaScript modules and > suggesting JavaScript add-ons. > > Now, by default, any JavaScript module can be monkey-patched. Some > developers prefer to Object.freeze() them, to ensure that this doesn't > happen, while others leave them open voluntarily and use monkey-patching > in test suites. > > Both approaches have their pros and cons. > > Do we/should we have a policy? > > Cheers, > David > > -- > David Rajchenbach-Teller, PhD > Performance Team, Mozilla > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
