Should mozilla::dom::Get{Entry,Incumbent,Current}Global be a static method of some class?

NEW
Unassigned

Status

()

P5
normal
4 years ago
4 months ago

People

(Reporter: bholley, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
Smaug asked me to file this. See bug 796938 comment 28.

IMO, they shouldn't, because they're already nested deeply enough in mozilla::dom. Opinions?

Comment 1

4 years ago
Nesting in namespaces doesn't really help at all.
When you see a method, it helps quite a bit readability if the name of the method tells you where it 
is defined and declared. That is why I really prefer static class methods over global (even if namespaced) ones.

(It would be rather nightmare if all the nsContentUtils methods were just globals in mozilla::dom)
(Reporter)

Comment 2

4 years ago
I guess the important differences between namespaces and static methods are:
(a) How many people |using| your namespace
(b) You have to declare all the static methods of a particular class in the same file

FWIW, I've been pretty happy with the assortment of xpc::Foo methods defined in xpcpublic.h, largely because I don't need to write 14 characters of boilerplace (strlen("nsContentUtils")) before I get to what I want.

Also, if this stuff still lives in mozilla::dom, then external consumers would have to do mozilla::dom::ScriptSettings::GetEntryGlobal, which is a bit of a mouthful.

I don't have a super strong opinion though. Thoughts Boris?
Flags: needinfo?(bzbarsky)
I'm rather partial to just names in namespaces, honestly.  Finding where a method comes from is something I do via mxr/dxr anyway, even for the ones with a class name in them....
Flags: needinfo?(bzbarsky)
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.