-
Notifications
You must be signed in to change notification settings - Fork 740
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
functions.xml Eliminate confusion in fn's parameters and arguments #4062
Conversation
If we agree that a) parameters are part of the function signature, i.e. an integral part of the function declaration, and b) arguments are information that comes to the function from the outside, then we must eliminate confusion in the text. To simplify it: the arguments are passed, and the parameters take values from the arguments and, after argument's expression are evaluated, set values for their parameters. If so, there seem to be inconsistent places in the text where parameters are passed and functions take parameters rather than arguments or something like that
This whole section needs a rewrite and reorganisation as how we talk about functions currently is clunky AF. |
If the current proposal does not contain errors, can we at least accept them and make global changes later? I have already made changes to the Russian version and received criticism from colleagues for the fact that the translation text deviates from the original. But I can't leave the literal translation either, because the current original confuses the reader by calling arguments parameters and vice versa. I would like the function parameters to remain parameters, and the arguments that the function receives from the outside to remain arguments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, this is a good change. I think we should merge it after few adjustments.
These terms matter mostly when there's ambiguity about what is discussed. In a lot of cases, you could use either term and it would still make sense.
As of PHP 8.0.0, the list of function arguments may include a trailing comma, which | ||
will be ignored. That is particularly useful in cases where the list of arguments is | ||
long or contains long variable names, making it convenient to list arguments vertically. | ||
As of PHP 8.0.0, the list of function parameters may include a trailing comma, which |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't this apply to argument list also?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This apply to argument list also, but in the example we see only list of parameters, but not the function call with aruments and trailing comma ;)
And from the context of the following sentence (even in the previous formulation), it is clear that we are talking about parameters — more precisely, about long parameter names in the function signature.
Perhaps the permissibility of passing arguments with an trailing comma should also be mentioned and an example of calling a function with a list of arguments and an trailing comma should be given.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps the permissibility of passing arguments with an trailing comma should also be mentioned and an example of calling a function with a list of arguments and an trailing comma should be given.
Perhaps you can do it in the next PR.
You may specify normal positional parameters before the | ||
<literal>...</literal> token. In this case, only the trailing arguments | ||
that don't match a positional argument will be added to the array |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this correct? I am actually confused about this whole sentence.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand it this way:
<?php
function someFn($one, $two, ...$other) {} // OK
function someFn(...$other, $one, $two) {} // Wrong (Only the last parameter can be variadic)
For example, after such a call someFn(1)
the $other
will stay an empty. But when the calling someFn(1, 2, 3, 4, 5)
, the trailing arguments (i.e. 3, 4, and 5) that don't match a positional argument (i.e. 1 and 2) will be added to the array ($other).
The paragraph looks like the correct text
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, this paragraph needs to be rewritten for clarity, but not in this PR. Maybe I will submit one PR later.
Co-authored-by: Kamil Tekiela <tekiela246@gmail.com>
Co-authored-by: Kamil Tekiela <tekiela246@gmail.com>
Co-authored-by: Kamil Tekiela <tekiela246@gmail.com>
Co-authored-by: Kamil Tekiela <tekiela246@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. It looks good to me and a definite improvement.
You may specify normal positional parameters before the | ||
<literal>...</literal> token. In this case, only the trailing arguments | ||
that don't match a positional argument will be added to the array |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, this paragraph needs to be rewritten for clarity, but not in this PR. Maybe I will submit one PR later.
If we agree that a) parameters are part of the function signature, i.e. an integral part of the function declaration, and b) arguments are information that comes to the function from the outside, then we must eliminate confusion in the text. To simplify it: the arguments are passed, and the parameters take values from the arguments and, after argument's expression are evaluated, set values for their parameters. If so, there seem to be inconsistent places in the text where parameters are passed and functions take parameters rather than arguments or something like that