I think that actually makes a lot of sense, and not just because of the supportability – but also because of security. A whole class of security exploits – buffer/stack overflows, underruns and all sorts of memory mismanagement become irrelevant when the code is implemented in PHP. I brought this direction up in a discussion on the Security mailing list a few weeks ago without any traction – but it probably makes more sense to discuss it here anyway.
I think that currently, there are two main challenges: 1. Performance – compute intensive logic is way slower in PHP compared to C. 2. Delivery method – we don’t currently have a good way of providing functions that are written in PHP and have them provide the same ‘native’ / ‘builtin’ experience as functions/classes written in C. Regarding #1, often this isn’t very important as not all pieces of code are that compute intensive. Moreover, if/when JIT materializes, compute intensive logic in PHP will become a lot faster than it is today and probably in the same ballpark as C – so it’ll open the door for us implementing more and more things in PHP. Regarding #2 – I think that’s something that can be solved relatively easily, but admittedly I haven’t completely thought it through (read: I barely thought about it). We could create a mechanism where the contents of certain .php files is embedded into the binary, compiled during MINIT, and made available pretty at the same ‘builtinness’ level as C extensions. We’d probably have to be pretty selective in terms of what goes in there – probably just as selective as we are with the C-based extensions, but I’d imagine that things like ext/exif, UUID, and perhaps even things like unserialize() could find themselves written in pure PHP using such a mechanism. Thoughts? Zeev From: Arvids Godjuks [mailto:arvids.godj...@gmail.com] Sent: Wednesday, September 6, 2017 2:43 PM To: Dan Ackroyd <dan...@basereality.com>; internals@lists.php.net Cc: Zeev Suraski <z...@zend.com> Subject: Re: [PHP-DEV] [VOTE] UUID I'd seriously start considering to start doing PHP code for things like these, so they are not bogged down by the fact that they are in C and there is 0.5 devs interested in supporting it. On Wed, 6 Sep 2017, 14:09 Dan Ackroyd <dan...@basereality.com<mailto:dan...@basereality.com>> wrote: On 5 September 2017 at 18:24, Fleshgrinder <p...@fleshgrinder.com<mailto:p...@fleshgrinder.com>> wrote: > Maybe I should stop the vote. The discussion is happening now instead of > before when I asked for it. We'll have to wait for at least six months > for another vote if this is a no, due to the rules. That would be fine and appropriate. The RFC targets 7.3. Having a discussion and vote in March gives plenty of time for getting it into 7.3 Cancelling a vote just to avoid an RFC being rejected is (imo) playing slightly fast and loose with the rules. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
