Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77942
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.169 as permitted sender)
Message-ID: <543C400E.4020603@gmail.com>
Date: Mon, 13 Oct 2014 22:11:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: PHP Internals List <internals@lists.php.net>
References: <CADyq6sJxBQ4Mcu9+LRedfFsV-ksdp26eqfWb_XdvP0EsDKS0Bw@mail.gmail.com> <CAPwsocG=mJRuNdzK=AoVOmuddcdZ0tag66fC1CEBWry1zrRndQ@mail.gmail.com> <CADyq6sJ6c233LXeL7BQ5eNsQOrcNdR5WwNfO=FfDk-67R0dojw@mail.gmail.com> <5439B266.8070300@gmail.com> <AC146B03-731F-41DD-906B-3477E14F3187@ajf.me> <CADyq6sKevr0M0W8d8RRGfsqdtSy5-vqjbRnTq23HRYXTzM1R2g@mail.gmail.com>
In-Reply-To: <CADyq6sKevr0M0W8d8RRGfsqdtSy5-vqjbRnTq23HRYXTzM1R2g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array()
 and related API
From: rowan.collins@gmail.com (Rowan Collins)

On 13/10/2014 01:45, Marco Pivetta wrote:

> In general, I've always been against any non-language feature that 
> isn't implemented with the language itself, but it's my point of view: 
> as a simple rule of thumb (my rule, many would just say I'm crazy), if 
> it can be implemented in PHP, then don't add it to core or extensions.

I think there are a few different ideas here which are worth unpacking.

Firstly, no language I can think of has ever been distributed or 
standardised without a standard library of functions. We all know that 
the abstractions we use *could* be reimplemented using lower-level 
structures, but knowing that an implementation is there "out of the box" 
means we don't need to spend time reinventing the wheel, or learning the 
subtleties of dozens of competing wheels. Along with syntax and a type 
system, the standard library is a key part of a language's identity.

Secondly, there is the question of "engine magic". I am actually rather 
sympathetic to the idea that userland code should *be able to* access 
more of the features that extension code can. For instance, object 
handlers written in C can implement many more hooks than userland 
objects can through magic __* methods and SPL interfaces, even when it's 
not the extension's purpose to manipulate the engine. I'd love it to be 
*possible* to write a version of SimpleXML in PHP. That said, there are 
some things which really do need a close integration with the engine to 
function correctly; variadics support is useful, but it clearly doesn't 
allow manipulation of the actual parameter passing logic in the way a 
debug extension might, and nor should it.

That does not, however, mean that all code that *can* be written in PHP 
*should* be written in PHP. High-level abstractions tend to come at a 
cost to performance, so it makes sense that many parts of a language's 
standard library are actually written in a lower-level language - in the 
case of PHP, that means implementing things in C; in the case of C, it 
might mean implementing them in assembly. Sometimes, too, it just makes 
more sense to keep everything in one place, such as if an extension is 
binding to an existing C library, but also provides some unique 
functions of its own.

Finally, there is the question of bundling and maintenance. A function 
distributed with core will have to be maintained by core developers 
whatever language it is written in. I guess having a section of the 
standard library written in PHP might attract more people to contribute 
to its maintenance, although the likely complexity of such code would 
probably still be intimidating to many. There's no reason that rewriting 
it in a different language would automatically make it optional - or 
that keeping it in C makes it automatically compulsory. PHP already has 
a modular structure, which distinguishes between mandatory, bundled, and 
externally maintained "extensions", so if we really wanted a "low fat" 
PHP we could just make more parts optional.

None of this should be taken as argument that anything and everything 
should remain in the core, but it does add up to a rather higher bar for 
removals or exclusions than "it's possible to do it another way, so we 
don't need to include this way".

-- 
Rowan Collins
[IMSoP]