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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
