Labs/Jetpack/Reboot/Best Practices: Difference between revisions

From MozillaWiki
< Labs‎ | Jetpack‎ | Reboot
Jump to navigation Jump to search
(added another bullet point)
(added note on use of 'new' operator.)
Line 15: Line 15:
* Some Cuddlefish modules, like file.js, take pains to be broadly compatible as JS modules and loadable as-is in Web pages, in addition to being SecurableModules used in Jetpack.  Do we really want to go that route for all modules?
* Some Cuddlefish modules, like file.js, take pains to be broadly compatible as JS modules and loadable as-is in Web pages, in addition to being SecurableModules used in Jetpack.  Do we really want to go that route for all modules?
* Creating code that can exist side-by-side with different versions of itself; implies not mutating the outside environment in certain ways.
* Creating code that can exist side-by-side with different versions of itself; implies not mutating the outside environment in certain ways.
* When creating objects, do we want <tt>jetpack.thing()</tt> or <tt>new jetpack.Thing()</tt>?
** Atul has found the case of forgetting the "new" operator to be unforgivingly difficult to debug.
** Atul has also found that "new" operator problems are hard to debug when the operator associates w/ a different operand than one intends, e.g. <tt>new require("foo").Bar()</tt>.

Revision as of 23:50, 1 February 2010

The following are best practices for reboot development. Nothing is (yet) set in stone, so propose and debate and stuff.

We also need to cover:

  • how to namespace packages (e.g., require("foo/bar/baz"))
  • out-of-code documentation (e.g., tutorials and guides)
  • unit testing
  • memory leak detection
  • module unloading
  • security
  • localization
  • API design
  • Some Cuddlefish modules, like file.js, take pains to be broadly compatible as JS modules and loadable as-is in Web pages, in addition to being SecurableModules used in Jetpack. Do we really want to go that route for all modules?
  • Creating code that can exist side-by-side with different versions of itself; implies not mutating the outside environment in certain ways.
  • When creating objects, do we want jetpack.thing() or new jetpack.Thing()?
    • Atul has found the case of forgetting the "new" operator to be unforgivingly difficult to debug.
    • Atul has also found that "new" operator problems are hard to debug when the operator associates w/ a different operand than one intends, e.g. new require("foo").Bar().