Syntax tweaks #5061
Merged
Syntax tweaks #5061
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
One thing I'm unsure about here is the instanceof syntax. It could also conceivably be Ideally we'd allow |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This allows operations that were previously allowed on constant strings on interpolated strings as well.
thekid
added a commit
to xp-framework/compiler
that referenced
this pull request
Feb 15, 2020
This was referenced Feb 15, 2020
elazar
pushed a commit
to elazar/PHPCompatibility
that referenced
this pull request
Nov 21, 2020
…g` sniff > Non-interpolated strings `"foo"` are currently considered fully dereferencable, i.e. constructions such as `"foo"[0]` or `"foo"->bar()` are considered legal (syntactically at least). However, interpolated strings `"foo$bar"` are non-dereferencable. > > This RFC proposed to treat both types of strings consistently, i.e. `"foo$bar"[0]`, `"foo$bar"->baz()` etc become legal. Ref: * https://wiki.php.net/rfc/variable_syntax_tweaks#interpolated_and_non-interpolated_strings * php/php-src#5061 * php/php-src@24e365f Includes unit tests. Relates to PHPCompatibility#809
elazar
pushed a commit
to elazar/PHPCompatibility
that referenced
this pull request
Nov 21, 2020
…g` sniff > Non-interpolated strings `"foo"` are currently considered fully dereferencable, i.e. constructions such as `"foo"[0]` or `"foo"->bar()` are considered legal (syntactically at least). However, interpolated strings `"foo$bar"` are non-dereferencable. > > This RFC proposed to treat both types of strings consistently, i.e. `"foo$bar"[0]`, `"foo$bar"->baz()` etc become legal. Ref: * https://wiki.php.net/rfc/variable_syntax_tweaks#interpolated_and_non-interpolated_strings * php/php-src#5061 * php/php-src@24e365f Includes unit tests. Relates to PHPCompatibility#809
elazar
pushed a commit
to elazar/PHPCompatibility
that referenced
this pull request
Nov 21, 2020
…g` sniff > Non-interpolated strings `"foo"` are currently considered fully dereferencable, i.e. constructions such as `"foo"[0]` or `"foo"->bar()` are considered legal (syntactically at least). However, interpolated strings `"foo$bar"` are non-dereferencable. > > This RFC proposed to treat both types of strings consistently, i.e. `"foo$bar"[0]`, `"foo$bar"->baz()` etc become legal. Ref: * https://wiki.php.net/rfc/variable_syntax_tweaks#interpolated_and_non-interpolated_strings * php/php-src#5061 * php/php-src@24e365f Includes unit tests. Relates to PHPCompatibility#809
elazar
pushed a commit
to elazar/PHPCompatibility
that referenced
this pull request
Dec 2, 2020
…g` sniff > Non-interpolated strings `"foo"` are currently considered fully dereferencable, i.e. constructions such as `"foo"[0]` or `"foo"->bar()` are considered legal (syntactically at least). However, interpolated strings `"foo$bar"` are non-dereferencable. > > This RFC proposed to treat both types of strings consistently, i.e. `"foo$bar"[0]`, `"foo$bar"->baz()` etc become legal. Ref: * https://wiki.php.net/rfc/variable_syntax_tweaks#interpolated_and_non-interpolated_strings * php/php-src#5061 * php/php-src@24e365f Includes unit tests. Relates to PHPCompatibility#809
jrfnl
pushed a commit
to elazar/PHPCompatibility
that referenced
this pull request
Dec 24, 2020
…g` sniff > Non-interpolated strings `"foo"` are currently considered fully dereferencable, i.e. constructions such as `"foo"[0]` or `"foo"->bar()` are considered legal (syntactically at least). However, interpolated strings `"foo$bar"` are non-dereferencable. > > This RFC proposed to treat both types of strings consistently, i.e. `"foo$bar"[0]`, `"foo$bar"->baz()` etc become legal. Ref: * https://wiki.php.net/rfc/variable_syntax_tweaks#interpolated_and_non-interpolated_strings * php/php-src#5061 * php/php-src@24e365f Includes unit tests. Relates to PHPCompatibility#809
elazar
pushed a commit
to elazar/PHPCompatibility
that referenced
this pull request
Dec 27, 2020
…rencing > ... class constant accesses are only array and object dereferencable. This > means that while `Foo::$bar::$baz` is legal, `Foo::BAR::$baz` is not. > > This RFC proposes to make class constant accesses static derefencable as > well, so that `Foo::BAR::$baz` and `Foo::BAR::BAZ` become legal. Ref: * https://wiki.php.net/rfc/variable_syntax_tweaks#class_constant_dereferencability * php/php-src#5061 * php/php-src@ab154b7 Includes unit tests. Relates to PHPCompatibility#809.
jrfnl
pushed a commit
to PHPCompatibility/PHPCompatibility
that referenced
this pull request
Dec 28, 2020
…rencing (#1262) > ... class constant accesses are only array and object dereferencable. This > means that while `Foo::$bar::$baz` is legal, `Foo::BAR::$baz` is not. > > This RFC proposes to make class constant accesses static derefencable as > well, so that `Foo::BAR::$baz` and `Foo::BAR::BAZ` become legal. Ref: * https://wiki.php.net/rfc/variable_syntax_tweaks#class_constant_dereferencability * php/php-src#5061 * php/php-src@ab154b7 Includes unit tests. Relates to #809. Co-authored-by: Matt Turland <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
RFC: https://wiki.php.net/rfc/variable_syntax_tweaks
This is a collection of minor syntactic extensions that cover holes left by the original uniform variable syntax RFC:
"foo$bar"is now treated the same ways as"foobar", e.g. you can write"foo$bar"[0].__FUNCTION__[0]becomes legal.Foo::CLASS_NAME::$barbecomes legal.new (expr)is now accepted. Previously it was not possible to use arbitrary expressions withnew.$var instanceof (expr)is now accepted.These are all edge cases, but things I've received complaints about over the years.