Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99405
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.128.172 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAF+90c9j4c+L8irb+tN+Qcx7SxA-d1EMBrXuZGw3FXi2SZr-Jw@mail.gmail.com>
References: <5313411f-40b4-58c6-83a8-7e813526f2a7@tekwire.net> <CAF+90c9j4c+L8irb+tN+Qcx7SxA-d1EMBrXuZGw3FXi2SZr-Jw@mail.gmail.com>
Date: Tue, 6 Jun 2017 11:55:46 -0400
Message-ID: <CAESVnVo_ZZRp72WrrQEGiMLG6e308Z0hrDOc5jhRPuy25Zej7w@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@tekwire.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core distribution
From: pollita@php.net (Sara Golemon)

On Tue, Jun 6, 2017 at 8:43 AM, Nikita Popov <nikita.ppv@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.