Le 07/03/2015 02:39, Yasuo Ohgaki a écrit :
We may provide new names and new parameter order in new namespace.
The difference is "alias" or "namespace" basically. I don't object to use
namespace for it at all. In fact, I would love to have it even if there is
issue
like writing extremely difficult to read code is possible.
Hello all,
I join the thread as a seasoned PHP developer (in user-space), not as a
PHP core developer. I work since 6 years now for large companies
websites and I write PHP scripts and programs since 15 years now. I
would like to bring my brick to this wall.
I follow the thread since a few days now and I have some suggestion
which can resolve both the functions naming issue for some of you, some
others suggested to have an object-oriented API and some are fearing
massive BC breaks.
I read Larry Garfield and Pierre Joye suggesting the idea of an
object-oriented API, maybe others suggested it already as long as this
idea is running here since a few years.
I wrote these days the start of a spec of an API, it is far from being
finished for the scalar types but the array part is almost finished and
integrates every method documented in the current array API.
https://github.com/gplanchat/php-oop-api
Suggestions are welcome, you can fork and comment. I don't have the
ambition to rewrite all the PHP core, but just using the existing
underlying code and applying it a new interface in the userspace.
Additionally to the current API.
I use the ideas from the [PECL SPL types
extension](http://php.net/manual/en/book.spl-types.php) and Nikita
Popov's [scalar objects extension](https://github.com/nikic/scalar_objects).
Those enhancements could be part of one RFC or several, as the amout of
work can be massive. The essential point is that this refactoring *MUST*
be using only existing code in the core. It *SHOULD* make it appear
differently to the user. The risk is then lower than a full refactoring.
It is, IMHO, the best compromise for the entire PHP community.
There are several goals and possibilities behind this :
* Create a consistent and complete API that can satisfy OOP programmers
and give them a more powerful API
* Do not create BC breaks on these core types, the ZVAL struct is
unchanged and the IS_STRING, IS-DOUBLE, ect... are still used as usual
* Make it possible in a future release (let's say PHP 8, 9 or 10+) to
deprecate and even remove the old API
* Build easily encoding-aware strings (binary, ASCII, UTF-8, UTF-16BE,
UTF-16BE, UTF-32, JIS, Big5, ect...)
Thanks for reading.
Grégory Planchat
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
