Skip to content

Rewrite and flesh out string interpolation docs #2000

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

Merged
merged 6 commits into from
Oct 2, 2024

Conversation

Girgias
Copy link
Member

@Girgias Girgias commented Nov 12, 2022

This covers the PHP 8.2.0 deprecation of interpolation It also renames simple to basic and complex to advanced as those don't make a judgement on complexity.

@Girgias Girgias requested a review from iluuu1994 November 12, 2022 14:04
@Girgias Girgias added this to the PHP 8.2 milestone Nov 12, 2022
Copy link
Member

@iluuu1994 iluuu1994 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only minor things, looks good to me overall.

<link linkend="language.types.string.parsing.simple">simple</link> one and a
<link linkend="language.types.string.parsing.complex">complex</link> one.
The simple syntax is the most common and convenient. It provides a way to
<link linkend="language.types.string.parsing.simple">basic</link> one and an
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The pages are still named simple and complex, should those be renamed? I'm also not sure this needs to be renamed at all.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't want to change them in case other pages link to here. But I could check and change them

]]>
</screen>
</informalexample>
The <link linkend="language.types.string.parsing.complex">advanced</link>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The basic one would be fine too for the first example.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well I was trying to have an example to demonstrate the reason why it is deprecated, so I copied the RFC example, but if you have a better example I'll take it :)

Copy link
Member

@iluuu1994 iluuu1994 Nov 13, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The error message only mentions {$var} because that will work for all versions of ${var}, like ${var['foo']}. That's not valid in the basic syntax (when translating 1:1), where the ' need to be omitted: $var[foo]. When only simple variables are used, $var should be fine as well.


<simpara>
If a dollar sign (<literal>$</literal>) is encountered, the parser will
greedily take as many tokens as possible to form a valid variable name.
Enclose the variable name in curly braces to explicitly specify the end of
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment seems kind of useful. Maybe move it to the advanced section instead?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would code using the advanced syntax use this? And isn't that part of the deprecation?

Copy link
Member

@iluuu1994 iluuu1994 Nov 13, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What this comment is saying that by enclosing the whole expression with {$...}, the parser doesn't need to guess when the expression is done (or rather stop after the first dimension) but will look for the ending } instead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What this comment is saying that by enclosing the whole expression with {$...}, the parser doesn't need to guess when the expression is done (or rather stop after the first dimension) but will look for the ending } instead.

No, this comment is referring to the ${...} syntax. If you read the current docs that's how it's used.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This section seems clear to me as @Girgias has changed it, enclosing just the variable name in brackets (${....}) was deprecated, but still explained in the warning that comes a bit later.

curly braces surrounding the expression.
</simpara>

<sect4 xml:id="language.types.string.parsing.simple">
<title>Simple syntax</title>
<title>Basic syntax</title>

<simpara>
If a dollar sign (<literal>$</literal>) is encountered, the parser will
greedily take as many tokens as possible to form a valid variable name.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find that statement a little misleading. The syntax isn't greedy, e.g. only one array dimension is allowed. https://3v4l.org/pJF8E

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well brilliant, this is already the existing docs but might as well fix them now. Do you have better wording? I can try to come up with one otherwise.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe something like:

The basic syntax only allows for single-dimensional array or property accesses.

$foods = ['apples', 'bananas', 'lettuce', 'spinach'];
echo "$foods[0]\n";
// apples

$foods = ['fruits' => ['apples', 'bananas'], 'vegetables' => ['lettuce', 'spinach']];
echo "$foods[fruits][0]\n";
// Warning: Array to string conversion in /in/hcu76 on line 7
// Array[0]

To use multi-dimensional array or property accesses, use the advanced syntax.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find that statement a little misleading. The syntax isn't greedy, e.g. only one array dimension is allowed. https://3v4l.org/pJF8E

Actually this statement is only about the name of a variable, not any following dimension. So I think it's correct.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what that statement is really about (there are still places in the docs where it talks about "variables" but means "values", what I consider grossly wrong). However, if it is only about the identifier, the word "token" doesn't make sense.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, braces don't change how the variable name itself is tokenized, so it's not even correct in that context.

@Girgias Girgias force-pushed the string-interpolation-deprecated branch from 33370e5 to a08df37 Compare November 14, 2022 15:03
@Girgias
Copy link
Member Author

Girgias commented Nov 14, 2022

I spent some more time again, can you please have another look @iluuu1994 @cmb69 ?

Copy link
Member

@cmb69 cmb69 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the PR!

I'm not convinced that this is a major improvement (but certainly causes quite some work for translators). Wouldn't it be better to have a precise description (like https://github.com/php/php-langspec/blob/master/spec/09-lexical-structure.md#string-literals)?

<warning>
<para>
The basic syntax does not permit access to an array entry which has a key
containing a minus (<literal>-</literal>) sign.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it makes much sense to point out that minus is not allowed, since AFAIK only valid identifier characters are allowed anyway.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are proably others yes, but when I was creating my example I used the array key string-key which when I tried to interpolate didn't work. So I changed the - to an _, however refering to that key is possible via the normal semantics.

Comment on lines 888 to 895
// Won't work, outputs: C:\folder\{fantastic}.txt
echo "C:\folder\{$great}.txt"
// Works, outputs: C:\folder\fantastic.txt
echo "C:\\folder\\{$great}.txt"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was a fix for https://bugs.php.net/81635. Not sure if we should just drop that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, okay I'll readd it then

@Girgias
Copy link
Member Author

Girgias commented Nov 14, 2022

Thank you for the PR!

I'm not convinced that this is a major improvement (but certainly causes quite some work for translators). Wouldn't it be better to have a precise description (like https://github.com/php/php-langspec/blob/master/spec/09-lexical-structure.md#string-literals)?

Having a more precise description would be best, but even that page has a dead link to what it refers to as "simple expression", and we would need to define what a name is somewhere.

Which might be a good idea to have a section on basic language components, because the amount of pages where we redeclare what a label is in PHP is too many.

But this is indeed probably the best course, I'll have another go at it.

@Girgias Girgias force-pushed the string-interpolation-deprecated branch from a08df37 to 5b7bcad Compare November 22, 2022 14:02
@Girgias
Copy link
Member Author

Girgias commented Nov 22, 2022

So I've given a go at trying to write a formal definition and removing the clunky descriptions and non-examples.

@@ -683,92 +683,167 @@ EOT;
</sect3>

<sect3 xml:id="language.types.string.parsing">
<title>Variable parsing</title>
<title>Variable substitution</title>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think using "substition" instead of "parsing" is an improvement (but there are 3 occurrences of "parsing" left on that page), but I think "variable substitution" is still not correct; at least with the advanced syntax, it is possible to interpolate the results of evaluating expressions. Speaking of "expression substitution/interpolation" would be too general, though. Not sure what to do here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm using string interpolation now

</simpara>

<simpara>
Any scalar variable, array element or object property with a
Any scalar variable, array element or object property
(<modifier>static</modifier> or not) with a
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TIL

This isn't called complex because the syntax is complex, but because it
allows for the use of complex expressions.
The advanced syntax permits the interpolation of
<emphasis>variables</emphasis> with arbitrary access expressions.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about "access expressions". Do we define that term somewhere? If not, it might be sensible to do that. Or maybe use "accessors"?

@Girgias Girgias force-pushed the string-interpolation-deprecated branch 2 times, most recently from 3676194 to 57ef188 Compare November 30, 2022 15:47
@Girgias
Copy link
Member Author

Girgias commented Jul 26, 2023

Note to self: related to #2078

@jimwins
Copy link
Member

jimwins commented Sep 29, 2024

The conflict is just in an example that should be easy to resolve. Otherwise, this is the last PHP 8.2 documentation issue still open on the tracker.

@Girgias Girgias force-pushed the string-interpolation-deprecated branch from 57ef188 to f6d7af4 Compare October 1, 2024 19:08
@Girgias Girgias requested a review from jimwins October 1, 2024 19:09
Copy link
Member

@jimwins jimwins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@Girgias Girgias merged commit b012e0d into php:master Oct 2, 2024
2 checks passed
@Girgias Girgias deleted the string-interpolation-deprecated branch October 2, 2024 15:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants