LXF79:PHP

Материал из Linuxformat.

Текущая версия

Что новенького в PHP 6

Что PHP грядущий нам готовит? Пол Хадсон (Paul Hudson) всегда на острие технологий и собирается показать нам, как использовать новые возможности.

Не только пионер должен быть всегда готов! В нашем мире программист программисту волк, так что не стоит пренебрегать ни одной возможностью усовершенствовать свой код. PHP 5.1 позволил подкрутить доступ к данным с помощью PDO и преподнёс множество маленьких ускорений по всей системе, но более крупные и всеобъемлющие изменения остались за горизонтом. Часть из них запланирована на версию 5.2, остальные — на PHP 6, но и те, и другие уже не за горами. Думаю, что релиз PHP 5.2 можно полностью пропустить, сосредоточившись на PHP 6, который уже совсем близко.

От изменения первой цифры версии мы обычно ждем нарушений обратной совместимости, множества новых возможностей и некоторых сюрпризов. В этой статье я собираюсь сосредоточиться на том, как PHP 6 может повлиять на ваши сценарии, и какие изменения потребуется в них внести, чтобы решить проблемы ещё до их появления. Но, пожалуйста, не забывайте, что PHP 6 ещё не выпущен, и изменения, о которых мы говорим тут, могут сами претерпеть изменения (и, скорее всего, так и будет) перед финальным релизом.

Универсальный переводчик

PHP — это язык программирования, который управляет сотнями тысяч web-сайтов, но при этом до сих пор, вопреки культурному разнообразию Интернета, очень плохо поддерживает Unicode. Когда вы создаёте новую строку или читаете её из базы данных, скорее всего, вы используете старый добрый ASCII. Существуют расширения для работы с многобайтовыми символами, но они ограничены кое-какими функциями и скромным набором строковых типов, и вы даже не можете гарантировать, что нужное расширение будет установлено на том сервере, где предстоит работать вашему коду.

PHP 6 будет первой версией с полноценной поддержкой Unicode. Сейчас полным ходом идёт работа по ее реализации во всех стандартных функциях. Внутри будет использоваться кодировка UTF-16, набор доступных символов в которой достаточен, чтобы писать на всех языках мира, живых и мёртвых: там могут оказаться даже такие фантастические языки, как клингон. UTF-16 используется в Java, .NET, Windows и других местах, так что для PHP это хороший выбор.

Проблема состоит в том, что добавление поддержки строк Unicode приводит к замедлению работы ваших сценариев. Конечно, если вы используете китайский или корейский язык, то у вас нет выбора, но тем, кому хватает ASCII, функции работы с многобайтовыми строками — это лишь в три раза более медленное решение, чем обычные. Так что если бы PHP 6 перевёл на UTF-16 всех, web-серверам пришлось бы пойти на вынужденное обновление аппаратного обеспечения одновременно с обновлением версии PHP, просто для того, чтобы обслуживать то же самое число страниц, что и раньше. Решение состоит в том, что в php.ini появилась опция, позволяющая прямо в процессе работы включать и выключать поддержку Unicode. На практике это означает, что провайдеры, скорее всего, отключат для вас поддержку многобайтовых строк, и вам придётся специально просить включить её.

Последнее прости

Изменение первой цифры версии — ничто, если оно не может нарушить обратную совместимость. Так что нет ничего удивительного в том, что некоторые хорошо известные возможности обречены на исчезновение из PHP 6. Первым будет отсечён, как и ожидалось, register_globals. Включенный по умолчанию в дни старого доброго PHP 4, он стал отключаться, когда появились суперглобальные массивы. Сейчас эта опция будет полностью удалена, и если вы попробуете её включить, то получите ошибку E_CORE_ERROR и ссылку на страницу документации. Вам стоило перестать использовать register_globals много-много лет назад, но если вы до сих пор не сделали этого, то теперь время вышло.

Что более удивительно, магические кавычки (magic_quotes) тоже умрут. Их проблема состоит в нарушении переносимости сценариев — одни люди считают magic_quotes полезными, другие — нет, так что в итоге вы никогда не можете предсказать, включено ли на сервере их использование. Решили эту проблему просто — опция magic_quotes полностью удалена, так что всем придётся самостоятельно расставлять слэши в своих переменных. Попытка включить magic_quotes в будущем тоже будет приводить к ошибке E_CORE_ERROR.

Но это ещё не всё. Мы попрощаемся с safe mode (давайте признаем, никто в здравом уме этот режим не использовал), с режимом совместимости с Zend Engine 1 (это была хорошая штука, но методы клонирования объектов в ZE2 гораздо полезнее), прольём скупую слезу по старым переменным $HTTP_*_VARS (с нами остаются наши друзья $_GET, $POST и так далее), и нежно простимся с функцией dl(). Да, динамическая загрузка расширений умрёт. Правда, это верно только для web, если вы используете CLI SAPI, то dl() вам по-прежнему будет доступна. По некоторым вещам мы даже не будем скучать — например, по <%, переходу в режим сценария в стиле ASP или по старой библиотеке для работы с графикой GD1 (просто возьмите вместо неё GD2).

Новые забавы

Из PHP 6 убрали многое, но кое-что при этом добавили. Призовые места среди новых возможностей занимают поддержка goto, функция ifsetor() и подсказки типов параметров и возвращаемых значений.

Третье место занимает поддержка goto. Нас всех учили в школе, что пользоваться goto — это плохо. Но ведь конструкция goto не есть абсолютное зло, и при умелом использовании она может сделать ваш код понятнее. Примерно два года назад был предложен патч, который добавлял в PHP поддержку goto, но его сразу же отклонили. Новое решение состоит в том, чтобы расширить функциональность ключевого слова break так, чтобы оно могло выполнять функции goto с тем исключением, что разрешаются только переходы назад. Главной проблемой goto было то, что он легко мог заплести код в спагетти — вы прыгаете вперёд, потом назад, прыжок за прыжком и так далее. Теперь, когда PHP ограничил возможности goto, вам придётся стать действительно некомпетентным программистом, чтобы использовать его неправильно.

Новая функция ifsetor() разработана для того, чтобы избежать нудного кода похожего на вот этот:

if (isset($_POST["MyVar"])) {
   $myvar = $_POST[ "MyVar"];
 } else {
   $myvar = "wombat";
 }

С ее помощью вы можете то же самое записать гораздо короче:

$myvar = ifsetor($_POST["MyVar"], "wombat");

Как вы видите, ifsetor() проверяет, установлен ли её первый параметр, и если да, то возвращает его значение. В противном случае она возвращает второй параметр.

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

<?php
   class Cat {
     public $Name;
     public function __construct($name) {
       $this->Name = $name;
     }
   }
   class Dog { }
   function meow(Cat $cat) {
     echo "$cat->Name says 'meow!'\n";
   }
   $toby = new Cat( "Toby");
   meow($toby);
 ?>

Использование параметра Cat $cat вместо просто $cat требует от сценария передавать только объекты типа Cat в качестве параметра функции. Если вы попробуете изменить Cat $cat на Dog $cat (требуя, чтобы передавался объект типа Dog), то получите ошибку. Самостоятельно такую проверку можно сделать с помощью instanceof следующим образом:

function meow($cat) {
   if ($cat instanceof Cat) {
     echo "$cat->Name says 'meow!'\n";
   } else {
     echo "That's not a cat!\n";
   }
 }

Подсказки типов возвращаемых значений делают функции PHP гораздо более C-подобными. Убедитесь сами:

function Cat Meow(Cat $cat) {
   /// code here
 }

В этом коде используется тип класса между ключевым словом и именем функции, и если код попытается вернуть из этой функции переменную иного типа, «зажжется» ошибка.

Под капотом

В последней версии PHP было сделано три «незаметных» изменения, которые тем не менее стоит иметь в виду всем программистам.

Во-первых, путаница с синтаксисом [ ] и {} увеличилась. В старые добрые дни [ ] использовали и для того, чтобы индексировать массивы, и для обращения к отдельным символам в строке. Но затем, «чтобы избежать путаницы», было предложено решение использовать [ ] для элементов массива и {} для отдельных символов из строки, вот так: $myarray[4] и $mystring{4}. Чтобы поддержать это изменение, индексирование строк через [ ] было объявлено как устаревшее в PHP 4. А теперь, после того, как мы переписали весь наш код на обращение к строкам через {}, разработчики PHP решили, что им всё-таки больше нравится [ ]. И они снова объявили его основным способом, а устаревшим стал {}. Так что конструкция $mystr[ ] раньше была неправильной, а теперь стала корректной, тогда как использование в PHP 6 $mystr{}, наоборот, будет ошибкой.

Ещё одной причиной для путаницы станет добавление 64-битного целого типа. Сейчас все целые занимают 32 бита в 32-битной системе и 64 бита на 64-битной. И эта разница (а также невозможность работать с очень большими числами на 32-битной платформе) превращается в проблему. В качестве решения было выбрано создание нового типа данных — int64. Обычные целые числа сохранят переменную битность, а вот int64 на любой платформе будет 64-битным.

Наконец, последнее изменение (а его действительно заждались) — стандартная поставка PHP теперь будет включать в себя кэширование скомпилированного кода. Если вы когда-нибудь использовали любую версию Zend Accelerator, то вы представляете, какое серьёзное ускорение он даёт. Alternative PHP Cache (APC) уже некоторое время является частью библиотеки PECL, но включение его в стандартную поставку означает, что настроить его будет гораздо проще. К сожалению, по умолчанию APC будет выключен, поскольку требует определенной настройки, но его присутствие — это уже большой шаг вперёд.

Конечно, на этих двух страницах я мог только слегка коснуться заявленной темы. Но я надеюсь, что я смог дать вам понять, в каких областях у ваших сценариев могут возникнуть проблемы при переходе на следующую версию PHP. PHP 6 уже доступен через CVS и довольно часто обновляется. Чтобы попробовать его, запустите

cvs -d :pserver:cvsread@cvs.php.net:/repository checkout php-src

и установите у себя. Но не забывайте — всё, о чём мы говорили (и всё, что вы можете скачать через CVS) может измениться к финальному релизу PHP 6.