stove/rougail
3
0
Fork 0
Code Issues 5 Pull requests 1 Projects Releases Wiki Activity

docs(v1.1_210): s/attribute/parameter/

Browse source
This commit is contained in:
gwen 2026-06-02 09:03:12 +02:00
parent c72b34cbf9
commit 7afb2c860c
1 changed files with 9 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
docs/tutorial/underscore_parameter.rst
View file

@ -3,15 +3,15 @@ Name and parameter conflict
.. objectives:: Objectives .. objectives:: Objectives
When a variable name conflicts with a family attribute, When a variable name conflicts with a family parameter,
do we have to abandon the variable name choice we made? do we have to abandon the variable name choice we made?
No because having a suitable variable name is really important. No because having a suitable variable name is really important.
The variable name you chose is undoubtedly the best. The variable name you chose is undoubtedly the best.
Sometimes, the choice of a variable's name may correspond very exactly Sometimes, the choice of a variable's name may correspond very exactly
to an attribute of the family in which that variable is placed... to an parameter of the family in which that variable is placed...
In this section, we will learn how to create a variable name that conflict with a defined attribute name. In this section, we will learn how to create a variable name that conflict with a defined parameter name.
.. prerequisites:: Prerequisites .. prerequisites:: Prerequisites
@ -42,19 +42,19 @@ We have this leadership family in its structure definition file:
:language: yaml :language: yaml
:caption: The `proxies` family with `leadership` type in the :file:`foxyproxy/00-foxyproxy.yml` structure file :caption: The `proxies` family with `leadership` type in the :file:`foxyproxy/00-foxyproxy.yml` structure file
The variable "type" that conflits with the family attribute "type" The variable "type" that conflits with the family parameter "type"
---------------------------------------------------------------------------- ----------------------------------------------------------------------------
Choice a good variable name is important. It's with this name that user will interact with here value. Choice a good variable name is important. It's with this name that user will interact with here value.
The user has to define the type of the new proxy. So instinctively the name of the variable will be `type`. The user has to define the type of the new proxy. So instinctively the name of the variable will be `type`.
But in the current family we have already the attribute `type` with the `leadership` value. But in the current family we have already the parameter `type` with the `leadership` value.
YAML do not permit to have two key with the same name. YAML do not permit to have two key with the same name.
Maybe we could choice an other variable name like `proxy_type` but the full path will be `proxies.proxy_type`. Maybe we could choice an other variable name like `proxy_type` but the full path will be `proxies.proxy_type`.
Repeating the word proxy is not appropriate. Repeating the word proxy is not appropriate.
So the best way it to rename the `type` attribute to `_type` So the best way it to rename the `type` parameter to `_type`
Let's create a family named `manual` which obviously corresponds to the proxy's manual configuration choice. Let's create a family named `manual` which obviously corresponds to the proxy's manual configuration choice.
@ -62,11 +62,11 @@ Let's create a family named `manual` which obviously corresponds to the proxy's
:language: yaml :language: yaml
:caption: The `proxies` family with `leadership` type and a variable with the name `type` in the :file:`foxyproxy/00-foxyproxy.yml` structure file :caption: The `proxies` family with `leadership` type and a variable with the name `type` in the :file:`foxyproxy/00-foxyproxy.yml` structure file
Technically it's possible to put `_` at the beginning of each attribute name, but it's still less readable. Technically it's possible to put `_` at the beginning of each parameter name, but it's still less readable.
.. keypoints:: Let's review the key points .. keypoints:: Let's review the key points
**Keywords** **Keywords**
- attributes could start by "_" character or not - parameters could start by "_" character or not
- do not add `_` in front of all attributes name - do not add `_` in front of all parameters name