On Tue, Jun 6, 2017 at 8:43 AM, Nikita Popov <nikita....@gmail.com> wrote: > First of all: I think the ability to implement parts of PHP extensions in > PHP is extremely important and will be a game changer in our ability to > maintain and improve our standard library. > Ditto this. The argument for having a MUCH larger pool of maintainers is #1. The reduced footprint for crash-bugs is a very close #2.
> Anyway, to get back to the topic of PCS. First, I would recommend to target > PHP 7.3 for this change. Feature freeze for 7.2 is in a bit over a month > and I think we'll want to make some non-trivial changes to how this works > if we integrate it in PHP. If added to PHP, I think this should be > integrated into the core, rather than being an extension. > As an RM for 7.2 *and* someone who's been daydreaming of something like PCS for awhile, I'm going to second this strongly. I literally cut the alpha1 tag this morning (for Thursday's official release), and something like PCS is pretty significant in its disruptive capacity (not to mention being lower-value until we start actually *moving* some of those extensions to PHP code). Save this for 7.3, please. > 2. It has already been mentioned in the thread, but what seems to lack > right now is a good way of integrating PHP and C portions. As far as I > understand, PCS allows you to write an entire class in PHP, but it does not > allow you to offload parts of the functionality to C without exposing > additional public APIs. I think there are two things we can do here: > > b) Allow binding some methods specified in PHP to an internal > implementation. The way this works in HHVM is that the PHP file contains > just a signature, with an attribute that signifies that an internal > implementation will be bound to that function: > As the author of HNI*, I look forward to iterating on this as a potential design (maybe learning from HNI's experience and making something better), but I regard it as a "version 2" thing. We can get PCS good and stable first, THEN worry about bridging to C later. > This would be useful for other reasons as well. In particular, this could > become a replacement for the existing arginfo-based signature > specification, which is somewhat limited and causes discrepancies with > userland classes. For example, arginfo does not support default values. > 100% this, though PHP's version of HNI will suffer a few shortcomings due to the lack of a type_traits equivalent in C99. I'm not suggesting we go C++11 just to get a better bridge, but it's a real constraint in getting the same advantages that HNI has. TL;DR - This is one giant "Me Too" response. :p -Sara * HHVM Native Interface. i.e. Exactly what Niki just described. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
