Заглянем в будущее PHP 6

Кирилл Сухов

Заглянем в будущее PHP 6

Смена версий у популярных программных продуктов, как правило, предполагает радикальные изменения в технологии или идиологии его использования. MySQL, PHP, Perl, PostgreSQL… и PHP тут совсем не исключение – в четвёртой версии было с нуля переписано ядро, в пятой появилась новая объектная модель.

В начале осени прошлого года на snap.php.net стали доступны версии шестой ветки препроцессора. Я предлагаю разобраться, что в них нового и чем эта версия, пока ещё прорисованная довольно смутно, отличается от предыдущих. В начале августа прошлого года разработчиками было принято решение – CVS HEAD был отделен в ветку PHP.5.1, после чего HEAD стал PHP 6.0.0. Означало это одно – все нововведения отныне стали применяться для этой, шестой ветки. Оставляя за PHP пятой версии только незначительные изменения и багфиксы. В середине августа Расмус Лендорф, основатель языка, в своём письме сообществу (http://news.php.net/php.internals/17883) высказал ряд пожеланий к шестой версии, которые это сообщество принялось активно обсуждать. В общем-то на тот момент отличие от «пятёрки» было только одно – полноценная поддержка Unicode. Обсуждение дало результаты – на ноябрьской встрече разработчиков в Париже были озвучены основные возможности, которые планируется воплотить в новой ветке.

В настоящее время идёт разработка, не утихают споры. Но некоторые контуры PHP 6 видны уже сегодня. Итак, приступим.

Отречёмся от старого мира

В первую очередь грядущая версия языка поражает не нововведениями, а количеством вещей, от которых решено отказаться. Разработчиков не трудно понять. PHP завоевал мир своей простотой и доступностью, но постоянно подвергался критике за низкую безопасность и слабую защиту от ошибок (от ошибок программиста, разумеется). Кроме того, во имя обратной совместимости со старыми версиями, язык тянет за собой устаревшие deprecated, которые были ещё уместны в PHP 3, но уже в PHP 5 кажутся полным анахронизмом.

Прежде всего «чистка» коснётся всем изрядно поднадоевших параметров в конфигурации интерпретатора – register_globals, magic_quotes и safe_mode, – из шестой ветки они будут изъяты. В версиях языка, до 4.2, все переменные окружения по умолчанию инициализировались автоматически. Это было, конечно, удобно для разработчика, но несло в себе огромную угрозу безопасности приложению, так как любой злоумышленник мог подменить значения переменных. Начиная с 4.2 параметр register_globals по умолчанию был выключен, оставляя возможность обращаться к переменным окружения через глобальные массивы ($_GET, $_POST, $_SERVER и т. д.), но многие приложения уже были написаны в старом стиле, и часто недалёкие авторы статей или книг советовали решить проблему, просто включив инициализацию. Теперь об этом можно будет забыть – и слава богу.

Директивы magic_quotes_gpc и magic_quotes_runtime отвечают за автоматическое экранирование некоторых спецсимволов. Они были разработаны для повышения безопасности, но на деле их использование создавало программисту дополнительные неудобства. Положение осложнялось тем, что эти опции любили включать хостеры.

С режимом safe_mode ситуация сложнее. Директива, введённая из соображений безопасности, устанавливает серьёзные ограничения на работу PHP-интерпретатора. При её включении пропадало большинство возможностей работы с файлами и каталогами (в частности затруднительно положить файл конфигурации выше директории веб-сайта, а ведь это разумная мера безопасности). С другой стороны, сам по себе режим safe_mode был далеко не панацеей и его ограничения  легко можно было обойти. Таким образом, он, не давая защиты, был вечной головной болью разработчиков. После его исключения исчезнет риск нарваться на хостинг с safe_mode=on. (Следует сказать, что функциональность директивы open_basedir будет сохранена.)

Что ещё? Поддержка таких древностей, как библиотеки Freetype 1 и (недоброй памяти) GD 1 также прекращается. Устраняется поддержка ASP-тегов (по сею пору <% можно после включения соответствующих настроек использовать на равнее с

Функция dl(), динамически подгружающая расширения PHP (и вызывающая своей некорректной работой многочисленные нарекания), будет сильно ограничена в правах, а именно – останется только в SAPI. При этом каждую функцию SAPI пройдется регистрировать отдельно. Честно говоря, не жалко, так как многие разработчики склонны рассматривать её существование почти как нелепость.

Расширение для работы с регулярными выражениями ereg будет удалено из дистрибутива и перенесено в репозитарий PECL. Я не думаю, что это повод для паники, так как подключить его – минутное дело, кроме того, уже в пятой версии языка рекомендуется использовать perl-compatible-регулярные выражения. Правда, разработчики пошли дальше и собираются перенести в PECL все расширения для работы с базами данных, за исключением PDO (расширение для унифицированного доступа к базам данных, введённое в версии 5.1). Этот шаг, конечно, логически обоснован, но пока выглядит страшновато.

Теперь о наведении порядка в синтаксисе.

Старые названия массивов (если точнее, старые массивы) вида HTTP_*_VAR из языка удаляются. Их применение вызовет ошибку уровня E_CORRE_ERROR. Старый синтаксис обращения к строковым индексам {} будет исключён, зато появится возможность получать символы от конца строки записью вида [4]. Оставшийся от PHP 4 синтаксис вида $foo=& new myClass(), или function &foo, в новой версии вызовет ошибку уровня E_STRICT (хорошо, что не выше – слишком много кода написано в стиле ООП PHP 4). Более того, поддержка ZE1 будет вообще исключена. В объявлении полей класса конструкция var (использующаяся в PHP 4, но приводящая к ошибке уровня E_STRICT в пятой версии языка), теперь уравнена в правах с модификатором public. Это безусловно послабление, но оно вполне укладавается в рамки «наведения порядка». Отпадает необходимость модернизации нескольких приложений, не списанных на PHP 4. Ну а чтобы совсем «добить» нерадивых разработчиков, сообщения об  ошибках уровня E_STRICT теперь войдут в E_ALL (при переходе на пятую версию параметры были разделены).

Что нового

Изъято довольно много, что предлагается в замен? Прежде всего поддержка Unicode. Для тех, кто не осознаёт важности момента, поясню – именно это послужило причиной смены номера версии. Дело в том, что по настоящий момент при разработке приложений приходится сохранять варианты имён методов, функций, переменных одновременно в двух таблицах символов – Unicode и non-Unicode. Решено обеспечить поддержку Unicode на уровне сервера (а не отдельного запроса, как было до сих пор). Соответствующие настройки будут храниться в файлах конфигурации и уйдут из поля зрения программиста.

Ранее PHP действовал как исключительно бинарный обработчик, тип байтовой строки был единственным и использовался для работы с любой информацией, что создавало (и создаёт) различные проблемы при работе с кодировками и национальными символами. В PHP 6 введёна возможность работать с типом данных «строка Unicode», реализованная посредством библиотеки ICU (International Components for Unicode). Использование ICU API позволило реализовать такие возможности, как корректная сортировка, с использованием любого национального алфавита, транслитерация, расположение текста для арабского, иврита, хинди и тайского языков, трансформации текста и многое другое.

Это касается не только обработки строк и летералов, но и кодировок HTTP-запросов скриптов и индификаторов. Андрей Змиевский в своём докладе на конференции в Москве в мае этого года привёл следующий пример кода:

class ....... {

function ... ......            { ... }

function !..$ ....)            { ... }

function ..........                   { ... }

}

$..... = array();

$.....[‘הָנָשׁ ַחוּלויְערַ’] = new .......();

Вообще поддержка Unicode в PHP 6 – это довольно обширная тема, заслуживающая отдельной статьи.

Не знаю, как относиться к следующей новости, но отныне гарантированна полная поддержка FastCGI, причём данная технология будет включена по умолчанию (без возможности отключения) для CGI SAPI.

Самое «вкусное» – PHP-акселератор APC, кэширующий сценарии в байт-код, будет теперь включён в ядро. Это, на мой взгляд, самое радикальное нововведение, и именно его я буду ждать. Кроме того, в дистрибутив решено включить расширения XML Reader (простой XML-парсер, основанный на SAX) и XML Writer (провайдер для XML API). Оба расширения, взятые из репозитария PECL, призваны значительно облегчить работу программиста с XML-документами. Из PECL также будет добавлено расширение Fileinfo.

Добавлен новый тип данных – init64, который будет соответствовать integer.

Ну и по мелочи: оператору break можно будет задавать метку, на которую будет перенесено выполнение программы после прерывания, станут возможны конструкции вроде следующей:

<?php

for ($i = 0; $i < 9; $i++)

{

        if (true) {

                break foo;

        }

        echo "not shown";

foo:

        echo "iteration $i\n";

}

?>

Foreach сможет работать с многоуровневыми массивами:

<?php

$a = array(array(1, 2), array(3, 4));

foreach( $a as $k => list($a, $b)) {

}

?>

в операторе ?: будет допустимо опускать первый параметр.

В объектную модель будет добавлен новый предикат static:: static2, позволяющий управлять static во время выполнения. Для иллюстрации его работы привожу пример кода:

<?php

        class A {

                static function staticA() {

                        self::static2();

                }

                static function static2() {

                        echo "A::static2\n";

                }

        }

        class B extends A {

                static function static2() {

                        echo "B::static2\n";

                }

        }

        B::staticA();

?>

Результатом работы будет вывод «A:static2».

Чего не будет

Чего точно не будет, так это типизации переменных. По мнению разработчиков. Это противоречит духу языка. Впрочем, есть идеи по поводу возможности типизации возвращаемых значений, но они пока не проработаны. Про пространство имён пока тоже речи нет, правда, есть слабая надежда, что в будущем его поддержка всё же появится.

Заключение

Вот тут хочу высказать некоторые сомнения. Когда появился (скорее слово неверное, он не появился, он проявлялся постепенно, как чеширский кот) PHP 5, у многих были сомнения, что хостеры вовремя предоставят возможность пользоваться новой версией. Эти сомнения в целом оказались напрасными – все ведущие площадки обновили интерпретатор довольно быстро. Проблема оказалась совсем в другой плоскости, а именно – в головах разработчиков. До сих пор и повсюду многие программисты, даже имея в своём распоряжении пятую версию, пишут на ней, как на четвёртой (это ещё в лучшем случае). Придется ли ко двору PHP 6? Время покажет.