On 10/8/13 10:09 AM, Benjamin Smedberg wrote: > On 10/8/2013 11:06 AM, Bobby Holley wrote: >> 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. > I'm of two minds about this. Having explicit extension points is a great > thing, especially if those points are tested. Monkeypatching is bad > engineering practice in general, and can both make it harder to change > things in our platform, and mean that extension break more often and in > bad ways. > > On the other hand, addons which made extensive changes to the browser > through monkeypatching have been some of the most innovative and > successful browser experiments. Perhaps there should still be a place in > the world for addons which do these sorts of things. Perhaps it just > means we should use addon static analysis to trigger extra review of > monkeypatching, and work with the code owners to add "real" > extensibility points to make it no longer necessary. > > At this point, I don't think that .freezing should be a best practice > (and we have more important things to do anyway). > > --BDS >
We already have pretty strict rules on AMO when it comes to monkeypatching, which is common practice when dealing with tab code. Our policy has always been to only allow it when there are no easy or viable alternatives. In general I think it's better to override an entire module via manifest declarations, rather than monkeypatching its code. However, it is very dependent on what needs to be done. Like with the Firefox tab code, generalized monkeypatching can be an indication that the code is not modular enough or could be otherwise modified to make it more extensible (for example, adding an observer notification for some event). Jorge _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
