My vote goes to 1 and A as well My sole argument is consistency; in general I'd rather start a namespace with a lowercase. So that when we have something like a scope resolution we know we are dealing with a namespace and not a class. But that's off-topic.
Namespace names are anyway not covered by our coding style, so it's probably worth adding an entry. https://www.gem5.org/documentation/general_docs/development/coding_style/ From a quick grep I can see most of our namespaces follow the PascalCase type, though there are some namespaces using snake_case convention. Giacomo > -----Original Message----- > From: Gabe Black via gem5-dev <gem5-dev@gem5.org> > Sent: 15 April 2021 09:03 > To: gem5 Developer List <gem5-dev@gem5.org> > Cc: Gabe Black <gabe.bl...@gmail.com> > Subject: [gem5-dev] Re: gem5 namespace > > My vote is for 1 and A. > > We have style rules for a reason, and that is because not following them > causes technical problems like name collisions, and makes it less obvious > when reading code what things are and what they're doing. It's a bit > hypocritical to say that we should follow style rules and completely ignore > the aesthetic rule when capitalizing GEM5_, but then say that the aesthetic > rule should win when dealing with the namespace. > > This is further inconsistent with the Gem5Internal namespace, the Gem5 > class in SCons, the Gem5Op instruction format used for ARM, and the > Gem5Imm constant used for ARM semihosting. It would also cause a collision > with any variable called gem5, a completely legal and reasonable name to use, > *especially* in code outside of gem5 which might be using it to refer to > something related to gem5 which it is interacting with. > > There are no other instances where we let superficial aesthetic conventions > like this overrule technical considerations. We don't add _tm to the end of > trademarked names, we don't call AtomicSimpleCPU the atomic simple CPU > since that's not a valid class name, and a hundred other examples of where > prose takes a back seat because this is not prose, this is a conceptual > machine > people happen to be able to read. > > Our website is the place for branding and identity and marketing, our code is > not. > > Gabe > > On Wed, Apr 14, 2021 at 7:28 AM Jason Lowe-Power via gem5-dev <gem5- > d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote: > > > Thanks for putting this all together, Daniel! > > My opinion is the same as yours: option 2 and macro A. > > One other thing we need to do is to standardize and document when > and where you need to use the gem5 namespace. For instance, do we need > to update *all* headers to be in the gem5 namespace? If not, when is an > object in the gem5 namespace and when it is not? What about `using > namespace gem5`? Can/must all .cc files include this? > > Since this is a relatively big change to the coding standards which > could cause significant frustration to our users, we should be sure to > document and standardize *before* we make any code changes. > > Cheers, > Jason > > > On Wed, Apr 14, 2021 at 6:48 AM Daniel Carvalho via gem5-dev > <gem5-dev@gem5.org <mailto:gem5-dev@gem5.org> > wrote: > > > Hello, devs, > > > > We currently have a recurring issue, which is the lack of a > gem5 namespace. > This generates collision with other libraries and user code. > > > > A Jira ticket has been created to point out the issue last year: > > > https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/G > EM5-730 > > > And this topic has been brought up a few times: > > > https://www.mail-archive.com/gem5- > d...@gem5.org/msg37770.html > > https://gem5- > review.googlesource.com/c/public/gem5/+/40878 > > https://www.mail-archive.com/gem5- > d...@gem5.org/msg36453.html > > > Finally, there were already patches that were consequences > of lack of a gem5 > namespace: > > > https://gem5- > review.googlesource.com/c/public/gem5/+/32175 > > https://gem5- > review.googlesource.com/c/public/gem5/+/40878 > > > A similar issue exists for macros, and an existing proposal to > solve it already > exists, which is to add a "GEM5_" prefix. It follows the coding > style, which > dictates that "preprocessor symbols (constants and macros) > should be all > caps with underscores": > > > > https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/G > EM5-912 > > > It does not seem to be controversial to add this namespace; > however, there is > still one blocker to greenlight its creation: what will be its > name. There are > no explicit rules regarding namespace naming; however, they > are typically > declared starting with an uppercase letter followed by > lowercase letters. So, > theoretically, gem5's namespace should be "Gem5". This, > however, conflicts > with gem5's identity: "“gem5” should always have a > lowercase “g”" > (see http://www.gem5.org/getting_started/). > > > > We should decide as a community what is the best approach > to take, so I'll > list the options and will request you to cast your votes. If you > would like > to add remarks to the discussion, feel free to do so. > > > > NAMESPACE: > > > 1 - namespace Gem5 {} > > > 2 - namespace gem5 {} > > > > MACROS: > > > A - GEM5_MACRO_NAME > > > B - gem5_MACRO_NAME > > > Personally, I think that identity precedes coding style, so > *option 2* should > be taken. Yet, in a slightly inconsistent manner, I would vote > for macro > *option A*. My argument being that it would be more > convenient to type it > with all caps, and that it would be implied from the identity > that it refers to > instances of the identity containing lowercase letters, which > is not the case > of "GEM5_". > > Best, > Daniel > > > _______________________________________________ > gem5-dev mailing list -- gem5-dev@gem5.org <mailto:gem5- > d...@gem5.org> > To unsubscribe send an email to gem5-dev-le...@gem5.org > <mailto:gem5-dev-le...@gem5.org> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > > _______________________________________________ > gem5-dev mailing list -- gem5-dev@gem5.org <mailto:gem5- > d...@gem5.org> > To unsubscribe send an email to gem5-dev-le...@gem5.org > <mailto:gem5-dev-le...@gem5.org> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
