Nothing gets software devs as engaged as when discussing naming conventions :).
I vote for "gem5" (lowercase) namespace, with all caps MACROS, but my sole reason for this is I've grown to flinch whenever I see "Gem5", which I admit isn't the best argument. I echo Daniel's comment that I care more about having a rule and moving past this than what that rule should be. -- Dr. Bobby R. Bruce Room 2235, Kemper Hall, UC Davis Davis, CA, 95616 web: https://www.bobbybruce.net On Sun, Apr 18, 2021 at 3:44 PM Daniel Carvalho via gem5-dev < gem5-dev@gem5.org> wrote: > Overall, there are way more uses of "gem5" than "Gem5" in the codebase, > and most of the instances that break the identity rule could be easily > fixed; however, there are cases that generate inconvenience: classes > starting with lowercase, and situations where gem5 is in the middle of the > var name (like "haveGem5Extension") make the code harder to > read/understand. In this sense, the uppercase version generates better > code. > > > I still favor namespace gem5 - it'd be the "external external" API, i.e. > we probably wouldn't be using it within src/ that much, and it would be > used by other simulators and within our SystemC bridge (more on that later) > - however, since we already have some exceptions, it wouldn't be the end > of the world having it start with a capital letter. > > > In the end, I personally do not care about which approach is taken, but > the decision taken must be taken as a community. Therefore, it would be > nice if we could have participation from other contributors to make the > final decision less susceptible to changes/complaints in the future. > > > Regarding when to use it: > IMHO (and not thoroughly thought out), all .cc and .hh and objects within > src/ should be subject to the namespace. Objects declared there are > declared and maintained by gem5. Because of that there would probably be > very few instances of namespace resolution within src/, so we should keep > avoiding "using namespace" and being verbose about it. Finally, we also > probably want to encourage users to define their objects inside the gem5 > namespace to make it less unlikely that they will give up on uploading > their contributions due to the different styles, and the laziness to adapt > code. This means that disturbance in user code would be minimal: they would > simply add "namespace (G|g)em5 {" in the beginning and "} // namespace > (G|g)em5" at the end, instead of multiple "(G)|gem5::" instances. > > > Regards, > > Daniel > For the record, if the namespaces you found using snake_case start with > sc_, those are for systemc and are mandated by that standard. The one > exception, sc_gem5, is one I made up which is closely associated with the > other systemc namespaces and is named similarly to them for consistency. > > Gabe > > On Thu, Apr 15, 2021 at 1:51 AM Giacomo Travaglini < > giacomo.travagl...@arm.com> wrote: > > 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
_______________________________________________ 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
