I'm confused, Jason. I thought you were in favor of adopting snake case as a
"general convention" (i.e., "the google way"), so by adopting snake case we
would be adopting the "general convention", not forging our own path. However,
if by "general convention" you mean "the convention vastly adopted by gem5", I
don't have the exact numbers, but I'd guess it is 70% pascal, 30% snake case -
i.e., IMHO, not a "general convention", just a preference. Adding "gem5" or
"Gem5" would only extend this mess, not add an exception.
Regarding changing the name of the variable, indeed, it is not a necessary step.
Again, as stated before, I don't care which solution is taken. The important
thing is to come to a decision that appeases most community members; however,
it is hard to reach a consensus when we seem to have strong opinions on both
sides, yet we only have 5 votes. That is why I have suggested officially
adopting snake case namespaces: it would solve the "gem5 VS Gem5" problem, it
is feasible to do it without having exceptions (at least as of now), Giacomo
expressed preference towards lowercase namespaces, Jason suggested affinity
with the google approach (snake case) and "gem5", Bobby prefers "gem5", and
Gabe and I like consistency/patterns. The (huge) downside to this solution is
that it would affect users, but 1) we'd already be affecting users anyway with
the new namespace, and 2) solving the merge conflicts would be straightforward
if the patches were created with that in mind.
Regards,Daniel
Em segunda-feira, 3 de maio de 2021 15:44:46 BRT, Jason Lowe-Power
<ja...@lowepower.com> escreveu:
Just a few quick replies below. Overall, I think we're being too focused on
"standards" and not on enough on ease of use. It's not a problem if there are
exceptions to guidance, if there's good reasons for the exceptions.
On Mon, May 3, 2021 at 11:36 AM Daniel Carvalho via gem5-dev
<gem5-dev@gem5.org> wrote:
As mentioned by Gabe in the Jira issue, some of the namespaces using snake
declared in the codebase case are defined as parts of a standard, and thus
cannot be modified. Realistically, this means that if we wanted to follow a
namespace naming convention, it'd be snake case: despite having way more
occurrences of pascal case namespaces, they are all "ours"; this means that,
although inconvenient, it would be doable to standardize all of them.
If we just say "all namespaces should be PascalCase. gem5, the name of this
project, is an exception" would be OK with me.
Would you be willing to adopt to enforce a snake case namespace naming
convention? From the previous replies to this thread, it seems that this
solution would appease most - if not all - participants.
I really don't think this is too important. I would definitely prefer to follow
the *general* conventions rather than forging our own path.
For this change to take place, we need to (not necessarily sorted):1) Rename
the python variables named "gem5" in src/systemc/tlm_bridge/TlmBridge.py (or
remove them - I don't remember finding where they are used);
Why does this need to be done? These are class names, not namespaces.
2) Add a section to our coding style mandating snake case for namespaces;
3) Change all existing namespaces to snake case;
4) Create a verifier to enforce this convention.
5) Rename/Move elements starting with gem5X/m5X as gem5::X
Finally, regarding macro names, we could improve the corresponding Jira issue
by listing all current macros so that we can start applying the change and
raise objections to particular instances.
Cheers,Daniel
_______________________________________________
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
