Open Bug 497820 Opened 15 years ago Updated 2 years ago

[HTML5] HTML5 parser should use mozilla:: instead of nsHtml5 for naming

Categories

(Core :: DOM: HTML Parser, defect, P4)

Product:
Core
Component:
DOM: HTML Parser
Version:
Other Branch
Type:
defect

Tracking

()

People

(Reporter: hsivonen, Unassigned)

Details

Need to migrate the translator and the hand-written C++ to the new mozilla namespace.
What should the naming and the source tree layout look like eventually, when we are going to have markup parser bits that are HTML-specific, that are XML-specific and that are shared between the two? I'm a bit worried that my work on the XML stuff is going to get blocked on naming things...
How about something like: parser/ <stuff that is shared> parser/html <html specific stuff> parser/expat <expat> parser/xml <xml specific stuff> (Potentially we'd even want to put the whole parser/ subtree under dom/, but that's an orthogonal issue which I don't think would affect what goes into the parser/ directory. It's likely something we could change when migrating all of content/ into dom/.) Definitely don't let naming discussions block you. For now you can just put whatever XML stuff you're doing in the parser/xml directory, and if needed have it use the existing stuff that lives in parser/html. Everything is linked into a single dll these days anyway.
Also, I'm mostly tossing out ideas to see what sticks, if you feel that they are missing something important then it's likely that they are :)
(In reply to comment #2) > parser/ > <stuff that is shared> > parser/html > <html specific stuff> > parser/expat > <expat> > parser/xml > <xml specific stuff> WFM. What about the file naming and the class naming? Instead of nsHtml5Foo in parser/html/nsHtml5Foo.h, do we want something like mozilla::parser::html::Foo in parser/html/Foo.h? And mozilla::parser::xml::Bar in parser/xml/Bar.h for XML? Should abstract classes still have an "A" in the name? Like mozilla::parser::AParser as a replacement for nsIParser? > Definitely don't let naming discussions block you. For now you can just put > whatever XML stuff you're doing in the parser/xml directory, and if needed have > it use the existing stuff that lives in parser/html. Everything is linked into > a single dll these days anyway. OK.
Sounds all good to me. We haven't really had the 'A' prefix in the past, but it sounds ok to me.
We've certainly used the A prefix before for non-XPCOM-interface abstract classes in the tree: nsAHttpTransaction, nsAHttpConnection, nsAXPCNativeCallContext, and so forth. The directories in comment 2 sound good to me. The namespaces in comment 4, I dunno. There's something to be said for a reasonably flat namespace so when I see 'Parser' in the code I (or a tool, for that matter) don't have to guess whether that's an html::Parser or an xml::Parser (or a css::Parser, for that matter!)... In any case, I'm not sure it makes sense to have the namespaces match the directory structure, since we might put this under dom/ In general, I think parser/html/Foo.h is fine, with exported stuff (if any) going under mozilla/parser or mozilla/parser/html as makes sense for now. Not sure what the matching namespaces should be, other than I think it makes sense for them to live under mozilla::dom (except for that SAX bit, of course.... <sigh>).
mozilla::dom works for me too. Which would mean that we'll end up with classes (and file-names) like HTMLParser
(In reply to comment #6) > The directories in comment 2 sound good to me. OK. > The namespaces in comment 4, I dunno. There's something to be said for a > reasonably flat namespace so when I see 'Parser' in the code I (or a tool, for > that matter) don't have to guess whether that's an html::Parser or an > xml::Parser (or a css::Parser, for that matter!)... Isn't it the whole point of namespaces to be able to introduce cases like that? > In general, I think parser/html/Foo.h is fine, with exported stuff (if any) > going under mozilla/parser or mozilla/parser/html as makes sense for now. Not > sure what the matching namespaces should be, other than I think it makes sense > for them to live under mozilla::dom (except for that SAX bit, of course.... > <sigh>). mozilla::dom WFM, even if as a knee-jerk reaction it kinda bothers me not to have the namespace and the directory structure match (maybe my thinking has been influenced by Java). Let's do mozilla::dom, since I don't expect the namespaces to provide real value, so shorter boilerplate is better. So basically, this would be just s/nsHtml5/mozilla::dom::/
Well, if the parser lives under mozilla::dom, I think it needs to be called HTMLParser, as we parse lots of things other than HTML.
(In reply to comment #9) > Well, if the parser lives under mozilla::dom, I think it needs to be called > HTMLParser, as we parse lots of things other than HTML. Yeah, I was kinda expecting that. The worse thing, though, is that we'd end up with stuff like mozilla::dom::AttributeName or mozilla::dom::TreeBuilder. Making these mozilla::dom::HTMLAttributeName or mozilla::dom::HTMLTreeBuilder would defeat the whole point of having namespaces. So I take my opinion about mozilla::dom:: back and revert to suggesting mozilla::parser::html::Foo.
> Isn't it the whole point of namespaces to be able to introduce cases like that? Yes, but that doesn't mean that introducing them is necessarily a good idea. Something to be looked at on a case-by-case basis, imo. As far as comment 10, would we just want mozilla::dom::parser::html::Foo?
(In reply to comment #11) > As far as comment 10, would we just want mozilla::dom::parser::html::Foo? What problem is solved by having both ::dom and ::parser there?
The problem that we have non-DOM parsers of various sorts? But I guess those could go in the toplevel "parser" namespace too....
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.