Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99411
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain tekwire.net does not designate 212.27.42.4 as permitted sender)
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
References: <5313411f-40b4-58c6-83a8-7e813526f2a7@tekwire.net>
 <CAF+90c9j4c+L8irb+tN+Qcx7SxA-d1EMBrXuZGw3FXi2SZr-Jw@mail.gmail.com>
Message-ID: <7932749b-526e-af50-4ba4-7f2bccb4749c@tekwire.net>
Date: Tue, 6 Jun 2017 19:47:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CAF+90c9j4c+L8irb+tN+Qcx7SxA-d1EMBrXuZGw3FXi2SZr-Jw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: fr
Subject: Re: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core distribution
From: francois@tekwire.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=)

Hi Nikita,

Le 06/06/2017 à 14:43, Nikita Popov a écrit :
> 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.

Agreed. My initial choice was to keep it as a separate extension. This 
was fine for a proof of concept but we cannot solve the points raised 
below without a tighter integration with the core. I would have liked to 
keep the coupling as loose as possible but solving the remaining issues 
is more important. So, let's consider 7.3 as the new target.

> 1. As far as I understand, PCS relies on autoloading. There are two 
> issues here: First, autoloading does not register symbols prior to 
> autoloading. This means that functions like get_defined_classes() will 
> not behave as expected. Second, autoloading does not support 
> functions. I think both of these problems can be solved with some 
> up-front symbol analysis. Lazily compiling internal functions should 
> not run into any of the problems we have with userland function 
> autoloading.

Right. PCS implements a workaround by loading the code containing 
functions at the beginning of each request. So, my plan was a future 
extension of the autoloading mechanism to functions (and constants).

The PCS autoloader already extracts symbols from the PHP code at 
registration time. So, PCS already has a list of the class, function, 
and constant names it manages. I don't know what you mean with 'Lazily 
compiling internal functions'. Autoloading, combined with opcache, 
avoids to execute the whole code at the beginning of each request but 
there are probably better alternatives.

> 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:
>
> a) Provide a mechanism that makes certain functions only available 
> inside extension PHP code. This would allow exposing some private PHP 
> functions which are only used in the internal implementation of the 
> extension.
>
> 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:
>
> class Bar {
>     <<__Native>>
>     function foo($args);
> }
>
> 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.

Implementing this may be  beyond my capacity but, if you agree, we can 
work together to implement solutions to these issues. Other volunteers 
are welcome too.

Regards

François