Notes from the code cleanup meeting

[rocal...@gmail.com]

Documentation
-- XPCOM rules are unclear (XPCOMGC may help)
-- String docs could be improved by including parameter names in APIs
-- Some docs not easy to find (make it easier to find hacking.html?)
-- developer.mozilla.org includes both internal and external APIs ---
need to support searching only internal or only external
-- Need documentation showing how to create a new XPCOM interface or
implementation
-- People aren't sure whether to trust the documentation
-- The array guide needs to be updated
-- Replacements for obsolete APIs should be documented

Tree structure
-- File renaming is now possible, we should use it
-- merge content/ and dom/ (the result should be called 'dom')
-- merge public/ and src/ (move files from both into the parent
directory)
-- make all test manifests use the reftest format so we can have a
single tree-wide test structure
-- get rid of the test_ prefix on mochitests
-- move third party libraries to topic-specific top level directories
(e.g. media/)

Code style
-- use bool
-- consider STL replacements for PR features
-- update portability guidelines
-- tighten style guidelines (at least so that new code follows an
existing style)
-- war on warnings: make warnings fatal module by module
-- make assertions fatal (at least on test machines)
-- document a simple cross-platform way to abort with a breakpad stack
-- pay more attention to cost-correctness

Code change needed
-- Places cleanup
-- editor
-- widget (compositor should help a lot)
-- docshell, especially testcases with infrastructure for testing
bfcache
-- merge presshell/prescontext
-- merge contentviewer/document
-- merge docshell/webshell
-- merge nsIFrame/nsFrame
-- removing XPCOM/OJI plugin support
-- move platform-specific plugin support logic to widget/
-- add test plugins
-- remove usage of obsolete API (nsIEnumerator, nsISupportsArray, etc
--- see wiki page)
-- frame constructor (bz)
-- XBL -> XBL2
-- Event unification (smaug)
-- clipboard and selection
-- merge libraries into gklayout as needed
-- convert fake namespaces (e.g. nsLayoutUtils) to real ones

[Robert Kaiser]

rob...@ocallahan.org wrote:
> -- war on warnings: make warnings fatal module by module

While this sounds nice, we probably run into a problem with each new
compiler version that adds additional warnings, like gcc tends to.
I usually try using a development distribution, and cookies, which has
fatal warnings already, tends to be busted on my local build system with
every major compiler upgrade.
There should be some way we can deal with this before we make them fatal
all over.

Robert Kaiser

[Shawn Wilsher]

I don't see it on here, but I thought we also discussed console cleanup.
One of the things that came up was not having CSS errors dump out to
stdout.

Cheers,

Shawn

[Joshua Cranmer]

rob...@ocallahan.org wrote:
> Documentation

> -- Some docs not easy to find (make it easier to find hacking.html?)

FWIW, db48x now graciously hosts the doxygen output of Mozilla at
<http://doxygen.db48x.net/mozilla/html/>. I use this (or at least, my
local version) heavily when looking for relevant libraries. Improving
these documentation pages (can be generated by running |make
documentation|) is probably worthwhile; in many cases, they're more
up-to-date than MDC docs, although it can be hit-or-miss and some
documentation is not formated in a why that doxygen likes (e.g., nsIFile).

> Code style

> -- war on warnings: make warnings fatal module by module

Something that was brought up that I feel worth mentioning here:
apparently, there used to be a mechanism to "blame" people for causing
warnings; could that be enabled again until a module gets fatal warnings?

> -- pay more attention to cost-correctness

I think that should say const-correctness, correct?

> Code change needed

> -- convert fake namespaces (e.g. nsLayoutUtils) to real ones

I know there was more discussion on namespaces than just this, but I was
forced to leave partway through the discussion. The key thing I'm
interested in is where/when namespaces come in, and conventions for
naming. Or has that not been decided yet?

[smaug]

rob...@ocallahan.org wrote:
> Code change needed
...
> -- Event unification (smaug)

This is probably event split, not unification.
But anyway, cleaning up the nsEvent/nsDOMEvent mess

[Jonas Sicking]

>> Code change needed
>> -- convert fake namespaces (e.g. nsLayoutUtils) to real ones
>
> I know there was more discussion on namespaces than just this, but I was
> forced to leave partway through the discussion. The key thing I'm
> interested in is where/when namespaces come in, and conventions for
> naming. Or has that not been decided yet?

I think we also discussed rolling out namespaces carefully since to many
(probably most) people in our codebase have little experience with
namespaces. We don't want to repeat the same mistakes of yesteryear,
such as the 'ns' prefix which was a poor poor-mans namespace.

/ Jonas