I'm with Jim that feature switches are a bad idea, and that add-on's are the best current and long-term option.
On Fri, Sep 11, 2015, at 12:40 AM, Tim Guan-tin Chien wrote: > Tell me what you think and tell me the problems. Complexity: the permutations of interacting features. The hardest thing about software development is reasoning about what the software does. Feature switches that interact with other features create exponentially more complex situations. Of course, not every feature interacts with every other feature, but feature switches require a much higher level of discipline than an explicit extension system. The safest implementations where features live in their own files that are dynamically enabled/disabled ends up looking like a nicely factored extension/add-on system. The major risk with feature flags is that they let you get away with cutting corners. In my time hacking on Thunderbird, I saw existing preference-controlled features and newly proposed ones that seemed trivial on their own; just a few lines of code and a pref. But these greatly increased the potential number of ways things interacted. Things would break and the provided patch in many cases was moving one or two lines of code around with no tests and no comments that would help ensure the code never moved again. Touching that code before tests was added was stepping into a minefield of potential breakage and pissed-off users. (:squib also hacked on Thunderbird, which is likely we he is also so vehemently against feature switches.) Add-ons are of course not a silver bullet, as your point iii* makes. If the code an addon author is trying to influence doesn't have a clean means of being influenced, we can encounter the hacks resorted to in Firefox addons where Function.toSource() and regexp transforms could be used or clobbering a function with a modified block of copied-and-pasted code. A great example of add-on based development is the atom text editor and its package-centric architecture. Everything is a package, with explicit consumed and provided services. This discipline and the effectively enforced modular architecture allowing only explicit coupling benefits both the core developers and the add-on developers. And the good news is that we're already going in this direction. Teams have had time to pay down technical debt. The Next Generation Architecture (NGA) work is explicitly about modularizing things with explicit contracts. The gaia-components and other web component efforts are about modularizing and encapsulating our UI widgets and avoiding CSS soup, etc. The future's so bright we gotta wear Mozilla-branded hats because the store doesn't sell shades[1]. Andrew 1: https://gear.mozilla.org/ PS: There are some proactive things we can do; I'm going to reply to Dietrich's post directly since my reply here is already long. _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
