Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110206
Message-ID: <7eae27b53f24606af676565aa93b288d58cb1bb9.camel@schlueters.de>
To: Dan Ackroyd <Danack@basereality.com>, Jakob Givoni <jakob@givoni.dk>
Cc: php internals <internals@lists.php.net>
Date: Mon, 18 May 2020 23:02:05 +0200
In-Reply-To: <CA+kxMuTCpUo4TKuC=cdTdv1p7AAc9-vdAQUq9vrf02+0J9aZRg@mail.gmail.com>
References: 
	<CAJmjfvU1z2C6r0XCnwZsuDFMy9LBdAaH-Uw8dQJgtAGuOe7H=g@mail.gmail.com>
	 <CA+kxMuTCpUo4TKuC=cdTdv1p7AAc9-vdAQUq9vrf02+0J9aZRg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] SPL development interest
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Fri, 2020-05-15 at 12:53 +0100, Dan Ackroyd wrote:
> Obviously, all of the following is my own personal opinion, and other
> people may have different opinions.
> 
> There are two main lessons learnt from the SPL experience.
> 
> i) Some APIs need to evolve separately from the PHP release
> schedule*.
> As otherwise any mistake in the design of the  API is locked in until
> the next minor release.
> 
> ii) PHP needs a better way of installing extensions. There was a lot
> of work done on this in https://github.com/FriendsOfPHP/pickle but
> that effort seems to have been abandoned after a huge amount of work
> was done for it.
> 
> If anyone has any info on what the problems were with the approach
> taken in that project, sharing that knowledge with the rest of the
> PHP
> community would be helpful in a new attempt to solve that problem.

I don't think this is the specific SPL learning.

The goal of having many of those things in SPL (aside from helly having
time and fun and doing things he liked) was that they were supposed to
be the "Standard". Having one "observer" interface around everywhere.
(picking that, since I never saw code using SPL's observer ...)

Having it in a pecl module (even with a better tool) doesn't make them
ubiquitous standards.

The fact is that the internals group is a good group to discuss how the
language itself should change, how the implementation should work. It
however isn't good in defining APIs and interfaces.

This is not only due to experience of the ones involved, but also since
best practices evolve. What PHP provides is locked in the BC trap.
Evolving it, changing it is hard.

Luckily we are not in the times SPL was created, but 15 or so years
later. We now have composer and a way smaller gap between C code and
PHP userland for such things.

It is now way simpler and way more approachable to put such things in
userland packages and have other groups (like PSR process) design
those.

In the rare case where a design shows obvious benefits, but is slow one
can consider putting it in C and then in the distribution, but we
should aim to keep as many things in userland as we can. Actual users
can simpler contribute their experience, it's simpler to debug, it's
simpler to evolve/replace.

APIs and interface in the implementation should be the basic
foundation, as unopinionated as possible and enable to build "nice"
interfaces in userland on top. Matching the framework of the week.

For these things having a "simpler way" to install extensions isn't
really critical. While rethinking PECL and its tooling is important!
(what is it's role, it's function? Regarding code ownership,
maintenance, hosting, being directory, offering [windows] build
services, distribution, ...) If somebody were willing to think through
all the related aspects and investing time on execution ... I'm happy
to share my thoughts in more detail, while they have no proposed path,
if somebody has the energy to drive it.



Of course the line between what to put in C or userland is complicated.
Let's take the iterators in SPL. A userland implementation will often
have something like
   function next() { $this->innerIterator->next(); }
in it. In userland code we need to do the function lookups each time.
In the extension the lookup can be cached and the call can be sped up.
With lots of iterator nesting and iterations over large collections
this can be notable. If it warrants doing it in C one can discuss. (I
haven't measured in PHP 7 days, but SPL contains pure PHP
implementations of these things if somebody is intrigued)

   For archaeologists on PHP internals: This is the reason helly added
   the set of zend_call_method functions and macros in zend_interface.h
   allowing the cached lookups over the previous call_user_function()
   in zend_API.h.


johannes