| 1 |
On Fri, 28 Apr 2017 16:39:45 +0200 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> Change the unset value tag to '@DEFAULT-UNSET' to ensure consistent |
| 5 |
> use of hyphen/underscore throughout eclassdoc. Before, one tag |
| 6 |
> (@ECLASS-VARIABLE) has used hyphen while also one (@DEFAULT_UNSET) |
| 7 |
> used underscore. Unify them to use the former since @ECLASS-VARIABLE |
| 8 |
> tag is more common (and hyphens do not require holding shift). |
| 9 |
> |
| 10 |
> Fixing all existing uses is perfectly within our power; however, I |
| 11 |
> think it would be reasonable to delay it and combine with other |
| 12 |
> eclass changes to avoid unnecessary cache regen. The script still |
| 13 |
> allows the old tag name for compatibility. |
| 14 |
|
| 15 |
I have a counter suggestion: |
| 16 |
|
| 17 |
1. Leave @ECLASS-VARIABLE as-is |
| 18 |
2. Leave @DEFAULT_UNSET as is |
| 19 |
3. Document that underscores are to be used for all new tags |
| 20 |
4. Add support for @ECLASS_VARIABLE that works the same as |
| 21 |
@ECLASS-VARIABLE |
| 22 |
5. Don't go out of our way to migrate to @ECLASS_VARIABLE, just let it |
| 23 |
occur over time, particularly in conjunction with other major |
| 24 |
changes. |
| 25 |
|
| 26 |
Mostly because @FOO_VARIABLE is suspiciously similar syntax to me as |
| 27 |
other ALL CAPS variables used as ENV tokens in Bash. |
| 28 |
|
| 29 |
And I can't think of a single instance where I've seen a language with |
| 30 |
a convention that used ALL CAPS terms in conjunctions with hyphens, |
| 31 |
( and regex with _ are ultimately simpler to reason about than ones |
| 32 |
with - ) |
Archives