ideas:php6
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
ideas:php6 [2014/02/17 13:25] – added AST and other updates pajoye | ideas:php6 [2017/09/22 13:28] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 8: | Line 8: | ||
Each of them will require a RFC then, at least for important or large changes. | Each of them will require a RFC then, at least for important or large changes. | ||
- | * OpCache | + | * OpCache |
* Improved and actual 64bit support | * Improved and actual 64bit support | ||
* Unicode support | * Unicode support | ||
Line 26: | Line 26: | ||
* bundle pecl's http (add http2 support too) | * bundle pecl's http (add http2 support too) | ||
- | ===== OpCache | + | ===== OpCache |
Opcache has been bundled with 5.5.0. A real integration did not happen yet while stabilizing it was the highest priority. | Opcache has been bundled with 5.5.0. A real integration did not happen yet while stabilizing it was the highest priority. | ||
Line 35: | Line 35: | ||
* Change opcodes to ease opcodes caching and optimization | * Change opcodes to ease opcodes caching and optimization | ||
* Add necessary changes to support JIT compilation to native, most likely only partial part of the running code (a function/ | * Add necessary changes to support JIT compilation to native, most likely only partial part of the running code (a function/ | ||
+ | * Get rid of compat API in OPCache about old PHP versions (some code still refers to PHP 5.1) | ||
Line 67: | Line 68: | ||
* https:// | * https:// | ||
+ | See [[ideas/ | ||
===== internals API Cleanup ===== | ===== internals API Cleanup ===== | ||
Line 75: | Line 77: | ||
This proposal could be extended to hash, as hashes are widely used as well for internal storage. | This proposal could be extended to hash, as hashes are widely used as well for internal storage. | ||
+ | |||
+ | Clean the APIs to have consistent ones. Actually, APIs are composed of functions and macros, some macros are lowercased written making think you 're using a function (zend_hash_add f.e) | ||
The stream API, as being very powerful, suffers from code duplication all over the place. We have stream/IO related functions in the engine, TSRM, main/ and ext/ | The stream API, as being very powerful, suffers from code duplication all over the place. We have stream/IO related functions in the engine, TSRM, main/ and ext/ | ||
Line 93: | Line 97: | ||
===== Improve OPcodes, compilation and runtime ===== | ===== Improve OPcodes, compilation and runtime ===== | ||
- | PHP mainly got new opcodes, growing in almost all major versions but never actually | + | PHP mainly got new opcodes, growing in almost all major versions but never actually |
Some of these choices cause us troubles with the recent additions (OpCache), like the absolute address usage for jump/call operations. | Some of these choices cause us troubles with the recent additions (OpCache), like the absolute address usage for jump/call operations. | ||
Line 100: | Line 104: | ||
Ideas posted on the list: | Ideas posted on the list: | ||
- | * AST based compiler (Julien) | + | * AST based compiler (Julien, Nikita) |
- | * Rewrite the engine | + | * Rewrite |
Also as much as I would like a full rewrite of the engine, it sounds very hardly possible to do it within a reasonable time-frame (say two years), except if we suddenly have a couple of developers working full time on this task. | Also as much as I would like a full rewrite of the engine, it sounds very hardly possible to do it within a reasonable time-frame (say two years), except if we suddenly have a couple of developers working full time on this task. | ||
Line 168: | Line 172: | ||
The 2nd option obviously has my vote. It has only advantages. Fully BC, no namespace pollution with hundred of aliases. However both options share the same challenge: Define a clean API. This has to be done carefully and quietly, without FUDs or trolls :) | The 2nd option obviously has my vote. It has only advantages. Fully BC, no namespace pollution with hundred of aliases. However both options share the same challenge: Define a clean API. This has to be done carefully and quietly, without FUDs or trolls :) | ||
- | + | ===== Scalar type hinting and return typing ===== | |
+ | |||
+ | PHP should never be a typed language, at least, on a mandatory basis. | ||
+ | We already had RFCs about scalars type hinting, which all had pretty nice BC implementations | ||
+ | https:// | ||
+ | |||
+ | For return type hinting, see https:// | ||
+ | Those two concepts become more and more crucial nowadays, and may be rethought for PHP6 as well. |
ideas/php6.1392643512.txt.gz · Last modified: 2017/09/22 13:28 (external edit)