>
> 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...
This is why I'm strongly in favor of lowercase gem5. When external projects
link to gem5 (which is *going* to happen), I think it's much better to use
the normative gem5 spelling. It would be very confusing for people to use
Gem5 in the code but gem5 in documentation/papers.
```
class MyExternalObj: public gem5::SimObject
{
};
```
Jason
On Mon, Apr 19, 2021 at 6:40 AM Bobby Bruce via gem5-dev <gem5-dev@gem5.org>
wrote:
> 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
_______________________________________________
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
