docs: Let's clarify bracket types naming#5915
docs: Let's clarify bracket types naming#5915keradus wants to merge 5 commits intoPHP-CS-Fixer:masterfrom
Conversation
| Nomenclature | ||
| ============ | ||
|
|
||
| Brackets |
There was a problem hiding this comment.
would it make sense for you, @localheinz @julienfalque @kubawerlos @SpacePossum ?
i see that sometimes we mix braces/brackets/parentheses, maybe it's worth to unify?
There was a problem hiding this comment.
I am for consistent naming, even if that requires renaming fixers and options!
There was a problem hiding this comment.
Do we want to rename (deprecate existing + introduce proxy) every fixer that uses old nomenclature within this PR, or maybe only discuss and prepare a list of fixers and options to rename, and create an issue or milestone for that?
There was a problem hiding this comment.
I think it would be best to create an issue to keep track of the related and necessary changes, then open individual pull requests.
I have already started as you can see in
- feat: Deprecate
NewWithBracesFixerand proxy toNewWithParenthesesFixer#7331 - feat: Rename
CurlyBraceTransformertoBraceTransformer#7333 - feat: Deprecate
CurlyBracesPositionFixerand proxy toBracesPositionFixer#7334 - feat: Deprecate
CompactNullableTypehintFixerand proxy toCompactNullableTypeDeclarationFixer#7339
|
@keradus WDYT about adding this: https://github.com/kubawerlos/PHP-CS-Fixer/blob/add_ExcludedPhrasesTest/tests/AutoReview/ExcludedPhrasesTest.php#L33 test for all the deprecated constants? |
|
not sure if I would like to use it with |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
My English, and language knowledge in general, is not good enough to know what are the appropriate names for |
|
https://en.wikipedia.org/wiki/Bracket covers this topic very thoroughly. Note that "bracket" is itself an overloaded term. Depending on region and context, it can refer to My preference is the following:
(As an aside, note that the |
|
I like @keradus's initial proposition. It's nice that every bracket type has a single-word name, and it seems consistent to me, as it doesn't mix up terms from the upper and the lower row from the Wikipedia table. |
This comment was marked as outdated.
This comment was marked as outdated.
e94f14a to
8146bf7
Compare
| Nomenclature | ||
| ============ | ||
|
|
||
| Brackets |
There was a problem hiding this comment.
Do we want to rename (deprecate existing + introduce proxy) every fixer that uses old nomenclature within this PR, or maybe only discuss and prepare a list of fixers and options to rename, and create an issue or milestone for that?
| Brackets | ||
| -------- | ||
|
|
||
| ref https://en.wikipedia.org/wiki/Bracket |
There was a problem hiding this comment.
| ref https://en.wikipedia.org/wiki/Bracket | |
| Within the codebase we use consistent naming convention for all type of brackets (`reference <[../src/Fixer/FixerInterface.php](https://en.wikipedia.org/wiki/Bracket)>`_): |
| +-------------+----------+--------+ | ||
| | ( ) | [ ] | { } | | ||
| +=============+==========+========+ | ||
| | parentheses | brackets | braces | |
There was a problem hiding this comment.
I see one problem here: according to the linked reference square brackets [] are called "brackets" in US english, but the project uses British english, where "brackets" is an alias for parentheses (). This seems little inconsistent, but if we treat it as our internal naming convention then it's fine 👍.
PS. is there any reason why we don't cover chevrons <> here?
There was a problem hiding this comment.
It's even more complicated when I read it again:
There are four primary types of brackets. In British usage they are known as round brackets (or simply brackets), square brackets, curly brackets, and angle brackets; in American usage they are respectively known as parentheses, brackets, braces, and chevrons. There are also various less common symbols considered brackets.
So it seems like we just use American english here on purpose. I am not against it, as I think it's better to use these dedicated names rather than "round|square|curly|angle brackets" for every fixer/option name. I just want to make conscious decision 🙂.
There was a problem hiding this comment.
@keradus what about custom tokens? Some of them could possibly be renamed just like block types (like CT::T_ARRAY_INDEX_BRACE_[OPEN|CLOSE]), but some are the missing pieces of built-in tokens (like CT::T_CURLY_CLOSE, where T_CURLY_OPEN is a native one), and it would lead to inconsistency 🤔.
And what about token transformers? Should we rename related methods and all the references that use old nomenclature?
There was a problem hiding this comment.
I wondered myself about renaming token transformers, since they also use and refer to constants from PHP which sometimes have inconsistent naming.
Perhaps it's best to keep them as they are, as they are used internally only?
There was a problem hiding this comment.
either keep them as-is, or have 2 custom tokens that are having same value under the hood.
(CT:: is public interface, custom fixers could use them too)
Outdated, new discussions have to be addressed
|
Following @GPHemsle's #5915 (comment) and what I mentioned in #7328, I believe we have the following options: Option A
Advantages
Disadvantages
Unclear
Option B
Advantages
Disadvantages
Unclear
Sources
(Feel free to add more) AsideAs an aside, in German these are all Klammern:
|

if we decide to go that path, we need to update some namings too, eg
new_with_braces