1259860 - Remove the ns* prefix and move everything into the mozilla:: namespace

Status: RESOLVED INCOMPLETE

(Core :: General, defect)

Description

[Seth Fowler [:seth] [:s2h]]

Right now we have a *lot* of classes with an ns- prefix in their name. There's really no reason for this now that we're using modern C++ with namespaces. It makes code unnecessarily verbose and reduces the usefulness of code completion (since you have to type more characters for useful completions to pop up). Plus, since we're not using it for newer code, it makes things stylistically inconsistent.

This bug will serve as a metabug for the effort to:

- Remove ns- prefixes. (i.e., rename nsFoo to Foo).

- Move things which are currently in the global namespace into the mozilla:: namespace. (Since namespacing is the purpose that the ns- prefix served originally.)

My plan is to go through the codebase directory by directory and perform this refactoring. There's no huge hurry on this - it's something I plan to work on basically to kill some time while I'm waiting for compiles - so it'll probably take a while to get done, but if others want to jump in and help out, that'd be great!

I'm going to CC some folks from various components who may have opinions on this. Feel free to jump in and comment, or to CC more people who may want to participate in the discussion.

Comment 1

[Masatoshi Kimura [:emk]]

I have a little concern about grepability of the source tree.

Comment 2

[Seth Fowler [:seth] [:s2h]]

(In reply to Masatoshi Kimura [:emk] from comment #1)
> I have a little concern about grepability of the source tree.

How do you think this would affect it?

Comment 3

[Masatoshi Kimura [:emk]]

For example, History would hit much more unrelated results than nsHistory:
https://mxr.mozilla.org/mozilla-central/search?string=History
https://mxr.mozilla.org/mozilla-central/search?string=nsHistory

Comment 4

[Mats Palmgren (inactive)]

After you land these name changes I think it would be a good idea to make
a list of all the old/new name pairs (including namespace(s)) so that someone
can make an automated update to the crash signature field in Bugzilla (adding
the new names, keeping the old).

I've seen it happen before that bugs are closed as WFM because there are no
new crashes reported, when the real reason is that the method was renamed.

Comment 5

[Seth Fowler [:seth] [:s2h]]

(In reply to Mats Palmgren (:mats) from comment #4)
> After you land these name changes I think it would be a good idea to make
> a list of all the old/new name pairs (including namespace(s)) so that someone
> can make an automated update to the crash signature field in Bugzilla (adding
> the new names, keeping the old).
> 
> I've seen it happen before that bugs are closed as WFM because there are no
> new crashes reported, when the real reason is that the method was renamed.

That's a good idea. I'll try to produce one of those lists for each name change bug. Do you know who I should needinfo to actually update the crash signature field? I have no idea how to do that.

Comment 6

[Seth Fowler [:seth] [:s2h]]

(In reply to Masatoshi Kimura [:emk] from comment #3)
> For example, History would hit much more unrelated results than nsHistory:
> https://mxr.mozilla.org/mozilla-central/search?string=History
> https://mxr.mozilla.org/mozilla-central/search?string=nsHistory

Yes, I can see that being true in particular for class names which are a single English word. We should probably take that into consideration.

FWIW, DXR or probably even an MXR identifier search wouldn't have the same problem. But it certainly is an issue for tools like grep.

Comment 7

[Mats Palmgren (inactive)]

(In reply to Seth Fowler [:seth] [:s2h] from comment #5)
> That's a good idea. I'll try to produce one of those lists for each name
> change bug. Do you know who I should needinfo to actually update the crash
> signature field? I have no idea how to do that.

Probably just file a bug under bugzilla.mozilla.org/Administration ?
I know we have updated the Crash Signature fields before, without sending bugmail,
but I don't recall who did it.  (it was for signature changes in Socorro)

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Comment 9

[Andrew McCreight [:mccr8]]

This is basically a meta bug that hasn't had anything filed against it for 5 years, so I'm just going to close it. If somebody wants to work on it, they can reopen it.