rfc:instanceof_improvements
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
rfc:instanceof_improvements [2020/05/19 18:55] – created maxsem | rfc:instanceof_improvements [2022/04/18 10:51] (current) – Move to withdrawn ilutov | ||
---|---|---|---|
Line 3: | Line 3: | ||
* Date: 2020-05-17 | * Date: 2020-05-17 | ||
* Author: Max Semenik, maxsem.wiki@gmail.com | * Author: Max Semenik, maxsem.wiki@gmail.com | ||
- | * Status: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
===== Introduction ===== | ===== Introduction ===== | ||
- | The elevator pitch for the RFC. The first paragraph of this section will be slightly larger | + | As currently implemented, |
+ | <code php> | ||
+ | var_dump(new MyClass instanceof MyClass); // true | ||
+ | </ | ||
+ | So far so good? What if we tried to use a scalar type? They can be specified as parameter types just like class names, right? | ||
+ | <code php> | ||
+ | $x = 123; | ||
+ | var_dump($x instanceof int); // false, right hand side is always treated as a class name | ||
+ | </ | ||
===== Proposal ===== | ===== Proposal ===== | ||
- | I'd like to propose to modify | + | Make '' |
<code php> | <code php> | ||
- | ' | + | var_dump(' |
- | ' | + | var_dump(' |
- | $logger instanceof " | + | $type = ' |
- | $foo instanceof | + | var_dump(' |
- | $foo instanceof $someObject:: | + | |
</ | </ | ||
+ | |||
+ | ==== Types to support ==== | ||
+ | This proposal covers only concrete scalar types '' | ||
+ | * '' | ||
+ | * '' | ||
+ | |||
+ | All attempts to check against these types would evaluate to '' | ||
+ | |||
+ | * '' | ||
+ | |||
+ | ==== Legacy type aliases ==== | ||
+ | There are several legacy types, supported only for typecasts: '' | ||
+ | |||
+ | ==== Constant expressions on the left hand side ==== | ||
+ | The current implementation has a shortcut where if there is a constant expression to the left of '' | ||
+ | * In Java, a variable is required on the left side of '' | ||
+ | * In C#, constant expressions to the left of '' | ||
+ | * None of these support type names as strings, so the latter use case has no direct analogs. | ||
+ | |||
+ | I can see two possibilities why such constructs might appear in code: | ||
+ | * An clueless developer trying to achieve with '' | ||
+ | * A code generator went astray and generates something dubious. | ||
+ | |||
+ | Considering this, I don't think that adding support for constant expressions on LHS would do our end users any good. I propose to continue shortcutting such cases to false (just to make sure they don't rely on this) and additionally let the developers know they' | ||
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
- | What breaks, and what is the justification for it? | + | This proposal doesn' |
===== Proposed PHP Version(s) ===== | ===== Proposed PHP Version(s) ===== | ||
- | PHP 8.0. | + | PHP 8.1. |
===== RFC Impact ===== | ===== RFC Impact ===== | ||
==== To SAPIs ==== | ==== To SAPIs ==== | ||
- | Describe the impact to CLI, Development web server, embedded PHP etc. | + | None. |
==== To Existing Extensions ==== | ==== To Existing Extensions ==== | ||
- | Will existing extensions be affected? | + | Don't see a reason why they should. |
==== To Opcache ==== | ==== To Opcache ==== | ||
- | It is necessary to develop RFC's with opcache in mind, since opcache is a core extension distributed with PHP. | + | None. |
- | + | ||
- | Please explain how you have verified your RFC's compatibility with opcache. | + | |
- | + | ||
- | ==== New Constants ==== | + | |
- | Describe any new constants so they can be accurately and comprehensively explained in the PHP documentation. | + | |
===== Open Issues ===== | ===== Open Issues ===== | ||
Line 45: | Line 70: | ||
===== Unaffected PHP Functionality ===== | ===== Unaffected PHP Functionality ===== | ||
- | List existing areas/ | + | Anything |
- | + | ||
- | This helps avoid any ambiguity, shows that you have thought deeply about the RFC's impact, and helps reduces mail list noise. | + | |
===== Future Scope ===== | ===== Future Scope ===== | ||
- | This section details areas where the feature might be improved in future, but that are not currently | + | I'm currently pondering about extending type casts which would also improve type system and make syntax more consistent, but it' |
===== Proposed Voting Choices ===== | ===== Proposed Voting Choices ===== | ||
- | What should be done about this (improve instanceof | + | Accept |
===== Patches and Tests ===== | ===== Patches and Tests ===== | ||
- | Links to any external patches and tests go here. | + | * WIP patch: https:// |
- | + | ||
- | If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed. | + | |
- | + | ||
- | Make it clear if the patch is intended to be the final patch, or is just a prototype. | + | |
- | + | ||
- | For changes affecting the core language, you should also provide a patch for the language specification. | + | |
===== Implementation ===== | ===== Implementation ===== |
rfc/instanceof_improvements.1589914546.txt.gz · Last modified: 2020/05/19 18:55 by maxsem