On 12/15/2016 11:38 PM, Augie Fackler wrote:
(I’m trying to be brief here - hopefully it doesn’t come across as upset,
because I’m not - mostly I was blindsided by a policy claim that I don’t
remember.)
On Dec 15, 2016, at 3:40 PM, Pierre-Yves David <pierre-yves.da...@ens-lyon.org>
wrote:
So, to sum up, my stance is "Let us not revisit decision made by Matt for a
while". Of course they might be case were we could make an exception if it is really
worth it. Code style does not seems to be high profile enough for that (and is a lot of
work to adjust).
In broad strokes, I agree that we should make an effort to not cause a wave of
sea change. My perception of this particular issue is that:
1) The codebase is already somewhat inconsistent (despite the efforts of mpm
and others) when it comes to constant naming
My perception (and apparently Kevin's too) is that the codebase is
currently consistent¹. A very quick check of the current code seems to
confirm it is consistent (but that was a quick check). So, I think you
need to back this statement with stronger fact than just your perception.
Note for all as we speak about advocating for changes. On a general
basis I expect people proposing changes to something established,
(especially, behavior changes (different this case)) to provides
extended details one around the following things:
- What's the current situation,
- What are the clear gains brought on the table by the new proposal,
- What are the drawback/cost of doing that change.
2) mpm’s preferred style conflicts with both what we do in our c (sigh) *and*
what the rest of the world does in Python (and most other languages)
I agree here. (However as said in the previous email, there is many
debatable choice in the current style. But the fact we have a style is
something I find good.)
3) Constants are becoming more common in our codebase than they used to be,
which is good.
I don't share this perception either, for the past five years I've been
using many constants in my Mercurial development and seen plenty used
too. But that is a perception. Can you provide data to support your
perception?
4) It’s not actually worth the amount of ink we’ve spilled on it right now.
I agree, this is part of why I'm putting style change inside the "Let us
not revisit decision made by Matt for a while" principle, we have been
using the current style for almost 12 years and our code base run. So I
would rather keep the status quo for now and focus on more urgent things
to discuss.
The sum of those things is that I’d prefer, in new code, to violate the
oral-history-only (that is, not codified in a check-code rule or other formal
coding style declaration) convention whereby constants are indistinguishable
from variables,
Actually, the "all lower case, no underscore" rule is written down
somewhere on the wiki:
https://www.mercurial-scm.org/wiki/CodingStyle#Naming_conventions
(note: the page can probably use an update)
> by acquiescing to the broader Python coding conventions on this
single issue. I don’t want to go back and fix up old code, just try and
move the clarity needle on new code.
So, given that I currently consider the code-base overall consistent
(until proven otherwise). I think there is value in consistency.
Of someone whats to make an extensive study and proposal of how we could
move from a consistent lower-case-consts style to a consistent
UPPER-CASE-CONST (better) style, that would be worse studying (to be
honest, the migration looks a bit scary)
In addition, given that Matt used to have strong feeling about
code-style consistency. I would appreciate, if that someone waited until
next October before doing so.
I’ve seen some people say they’re fine with such a new policy, and many
contributors (including me when I’m on autopilot, despite a decade of history
with this codebase) are doing it by default, which was the thing that really
pushed me toward making this proposal.
I’m fine to explicitly defer this (until the next sprint perhaps? Would that be
far enough in the future?), if that’s what the broader community (rather than
just one person) would like. I’m also fine to hear the proposal rejected on its
merits (rather than a “we’re not changing things now” policy),
[extracted the last bit on it own line to clarify what I'm replying to]
> but I haven’t heard any objections to the actual proposal, only the
timing.
That part is confusing to me, two emails ago, on this thread, Kevin
voted -0 on the proposal. (You are replying to my reply to that Kevin's
email.)
Possible steps forward: we agree to discuss this at the sprint (so probably
March), knowing that I'll probably want to go and do invasive cleanup of
constants in network-related code at that time, or we actually discuss making
the policy change now so we can avoid future churn. Thoughts? I’m open to other
paths as well.
Here is the things that are important to me (from most important to
least important):
* Before we decide something, I would like an assessment of the current
situation in the code base and some actual plan(s) of how to do the
migration (and to what extend).
* This seems like a discussion more suited for a Sprint than emails,
* I would prefer we wait until October before having serious talk about
this. Both because we probably have more important matters to focus our
energy by then and out of respect for Matt opinion.
Cheers,
--
Pierre-Yves David
[1] sure there is a handful of exception.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
