ideas:php6
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
ideas:php6 [2014/02/17 06:05] – mroe details pajoye | ideas:php6 [2014/04/02 11:25] – jpauli | ||
---|---|---|---|
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 | ||
* internals API Cleanup | * internals API Cleanup | ||
* Warning free code | * Warning free code | ||
- | * Improve OPcodes, compilation and runtime (perf, features, jit, fixed address jump usage, etc) | + | * Improve OPcodes, compilation and runtime (perf, features, jit, fixed address jump usage, etc) |
+ | * JIT compiler (libjit?) | ||
* Annotation Support | * Annotation Support | ||
+ | * Named argument | ||
+ | * Scalar Type hinting | ||
* HTTP2 support (avoid our own implementation, | * HTTP2 support (avoid our own implementation, | ||
* Reliable, userfriendly RNG APIs (internally and userland) | * Reliable, userfriendly RNG APIs (internally and userland) | ||
* Getter/ | * Getter/ | ||
* Userland APIs improvement for all PHP types (OO instead of breaking BC) | * Userland APIs improvement for all PHP types (OO instead of breaking BC) | ||
- | * JIT compiler (libjit?) | ||
* C++ Usage | * C++ Usage | ||
* inclusion of the new crypto extension (maybe support other backends than openssl) | * inclusion of the new crypto extension (maybe support other backends than openssl) | ||
Line 33: | 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 65: | Line 68: | ||
* https:// | * https:// | ||
+ | See [[ideas/ | ||
===== internals API Cleanup ===== | ===== internals API Cleanup ===== | ||
Line 73: | 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 95: | Line 101: | ||
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. | ||
- | It would be interesting to begin a discussion about what we could change to make them more efficient and maintainable in the long run. It is also necessary to think long term, like how can we support JIT compilation to native code from the OpCode (full or partial). | + | It would be interesting to begin a discussion about what we could change to make them more efficient and maintainable in the long run. It is also necessary to think long term, like how can we support JIT compilation to native code from the OpCode (full or partial). |
+ | |||
+ | Ideas posted on the list: | ||
+ | * AST based compiler (Julien, Nikita) | ||
+ | * Rewrite parts of the engine (https:// | ||
+ | |||
+ | 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. | ||
+ | |||
+ | ===== JIT compiler ===== | ||
+ | |||
+ | JIT compiler to native code would be a huge step forward for the engine. As it won't bring it to the performance level of HHVM, it may be much better than what we have now and open full new areas to our users. | ||
+ | |||
+ | It is by far the most complex tax in this document but the effort is worth it. It can also be done step by step, full JIT support (as in get all parts of the running code JIT' | ||
+ | |||
+ | There are a couple of choices when it comes to JIT compilation. One of them which sounds like the best choice is LibJIT. It is well maintained, supports all architecture we need, and we have a developer knowing it very well (hey Gopal! ;). | ||
+ | |||
+ | Dmitry told me that he had made some experiment with a php specific version but is not allowed (yet?) to talk about the results or which strategy was used. | ||
+ | |||
+ | However, I won't recommend to go down our own way for this feature. It will drastically increase the time and effort to implement, stabilize and make this feature available on all supported platforms. | ||
+ | |||
===== HTTP2 support ===== | ===== HTTP2 support ===== | ||
Line 109: | Line 135: | ||
A cleaner solution would be to go with a more modern HTTP client/ | A cleaner solution would be to go with a more modern HTTP client/ | ||
+ | ===== Native Annotation Support ===== | ||
+ | |||
+ | A first attempt to add native annotation support to the core has been rejected: | ||
+ | |||
+ | https:// | ||
+ | |||
+ | In the meantime, the same format and concepts became a de facto standard in the PHP communities. Leading projects use and support annotations. | ||
+ | |||
+ | PHP must support annotation in its core. Annotation support should be designed and implemented with the support of the communities (Symfony/ | ||
===== Reliable, userfriendly RNG APIs ===== | ===== Reliable, userfriendly RNG APIs ===== | ||
Line 115: | Line 150: | ||
+ | ===== Getter/ | ||
+ | |||
+ | A new getter/ | ||
+ | |||
+ | https:// | ||
+ | |||
+ | The lesson of this RFC told me that almost everyone agrees that the current getter/ | ||
+ | |||
+ | I would suggest to take a 2nd look at this RFC and get new clean and usable getter/ | ||
+ | |||
+ | |||
+ | ===== Userland APIs improvement for all PHP types ===== | ||
+ | |||
+ | One of the top complains about PHP is the lack of consistent APIs. While most of them are true, we cannot simply suppress or change them, even not in a major version like 6. The pain introduced by such changes would be fatal from an adoption point of view. | ||
+ | |||
+ | Alternatives solutions to change all existing functions have been proposed. Two have got more attention: | ||
+ | |||
+ | * Create aliases | ||
+ | * Add OO APIs for all core types | ||
+ | |||
+ | 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.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1