Перевёл Бресь Сергей, http://phpclub.ru/
Одной из главных составляющих планируемой 5-й версии PHP станет Zend Engine 2.0, поддерживающий совершенно новую модель объектно-ориентированного программирования. Эта статья описывает развитие поддержки объектно-ориентированного программирования в PHP, включая новые возможности и изменения, запланированные в PHP 5.
Об этом знают немногие, но когда то, что сегодня известно как PHP, только формировалось летом 1997 года, — не планировалось, что оно будет иметь какие-либо объектно-ориентированные возможности. Andi Gutmans и я работали над созданием мощного, надёжного и эффективного web-языка, основанного главным образом на PHP/FI 2.0 и синтаксисе языка C. В сущности, мы были достаточно далеки от каких-либо намерений относительно классов или объектов — это должен был быть просто структурированный язык. Однако, в одну из тех летних ночей, 27 августа всё изменилось.
Классы были добавлены в код, ставший основой версии PHP 3.0. Добавлены они были как синтаксическое украшение для организации доступа к наборам данных. PHP уже поддерживал понятие ассоциативных массивов, и добавленное новшество было ничем иным, как новым необычным способом доступа к подобным наборам. Тем не менее, как показало время, этот новый синтаксис оказал гораздо более серьёзное влияние на PHP, чем планировалось изначально.
Ещё одним неизвестным для большинства фактом является то, что в пору официального появления PHP 3.0 в середине 1998-го, когда он ошеломляющими темпами набирал силу, Andi Gutmans'ом и мной уже было решено переписать реализацию языка. PHP мог нравиться пользователям в существующем виде (на самом деле, мы знали, что он им нравится), но как создатели двигателя мы знали, что творится под капотом, и мы не могли с этим мириться. Переписанный код, позже получивший прозвище 'Zend Engine' (Zend является комбинацией Zeev и Andi), положил начало и стал одной из основных составляющих второй перестройки, которую пережил PHP за период чуть более года.
Тем не менее, эта перестройка оставила объектную модель PHP, по большей части, не изменившейся с версии 3 — она всё ещё была упрощённой. Объекты до сих пор в значительной мере были синтаксическим украшением для ассоциативных массивов и не предоставляли пользователям достаточного количества дополнительных возможностей.
Итак, что мы могли делать с объектами во времена PHP 3.0 и даже в текущей версии PHP 4.0? На самом деле, — немногое. Объекты были по сути дела хранилищами свойств, наподобие ассоциативных массивов. Наибольшим отличием являлось то, что объекты должны были принадлежать к какому-либо классу. Классы, как и в других языках, содержали набор свойств и методов (функций), и экземпляры объектов могли создаваться из них с помощью оператора new. Поддерживалось единичное наследование, позволяющее пользователям расширять (или сужать) рамки существующего класса без необходимости писать класс наново или создавать его копию. Наконец, PHP 4.0 также добавил возможность вызывать методы заданного класса как в контексте использования объекта, так и вне его.
Одним из важнейших поворотных моментов в истории PHP было то, что, несмотря на очень ограниченную функциональность и массу проблем и ограничений, объектно-ориентированное программирование в PHP процветало и становилось самой популярной парадигмой увеличивающегося числа законченных PHP-приложений. Эта тенденция, бывшая по большей части неожиданной, поставила PHP в невыгодное положение. Начинал проявляться тот факт, что объекты вели себя не как в других ОО языках, а как ассоциативные массивы.
Самой проблематичной стороной объектно-ориентированной модели PHP 3 / PHP 4 было то, что объекты передавались по значению, а не по ссылке. Что это означает?
Скажем, у вас есть простая, несколько бесполезная функция, называемая myFunction():
<?php
function myFunction($arg) {
$arg = 5;
}
?>
и вы вызываете эту функцию:
<?php
$myArgument = 7;
myFunction($myArgument);
print $myArgument;
?>
Как вы, наверное, знаете, вызов myFunction() не изменит $myArgument; переданное в myFunction() — это копия значения $myArgument, а не сама переменная $myArgument. Этот способ передачи аргумента называется передачей аргументов по значению. Передача аргументов по ссылке { По-моему, — это опечатка; думаю, имелось в виду — "по значению". } реализована почти во всех структурированных языках и чрезвычайно полезна, так как позволяет вам писать свои или вызывать чужие функции, не беспокоясь о побочных эффектах, которые они могут оказать на "внешние" для них переменные.
Однако рассмотрим следующий пример:
<?php
function wed($bride, $groom) {
if ($bride->setHusband($groom);
$groom->setWife($bride)) {
return true;
} else {
return false;
}
}
wed($joanne, $joe);
print areMarried($joanne, $joe);
?>
(Реализации Woman::setHusband(), Man::setWife() и areMarried() опущены как упражнение читателю).
{ wed — "жениться", bride — "невеста", groom — "жених", husband — "муж", wife — "жена", areMarried — "они женаты?" }
Что возвратит areMarried()? Можно надеяться, что двое новобрачных сумеют остаться женатыми, по крайней мере, до следующей строчки кода, но, как вы могли догадаться, — не останутся. areMarried() подтвердит, что они развелись, как только женились. Почему?
Причина проста. Из-за того, что объекты в PHP 3.0 и 4.0 не являются чем-то особенным и ведут себя как любые другие переменные, — когда вы передаёте $joanne и $joe в wed(), на самом деле вы передаёте не их. Вместо этого, вы передаёте их точные копии, дубликаты. Таким образом, хотя их копии и женятся в wed(), действительные $joe и $joanne остаются на безопасном расстоянии от таинства священного брака, в своей защищённой внешней области видимости.
Конечно, PHP 3 и 4 дают вам возможность принудительно передать переменные по ссылке, позволяя, таким образом, функциям изменять аргументы, переданные им из внешней области видимости. Если бы мы определили прототип wed() так:
<?php
function wed(&$bride, &$groom)
?>
то для Joanne и Joe всё сложилось бы более удачно (или менее, в зависимости от вашего на то взгляда).
Однако, всё намного сложнее. К примеру, что если вы хотите вернуть объект из функции по ссылке? Что если вы хотите вносить изменения в $this внутри конструктора, не беспокоясь о том, что может произойти, когда они в результате выполнения оператора new скопируются в переменную-контейнер? Не знаете, о чём я?.. Скажите "аллилуйя" { а лучше прочитайте раздел References inside the constructor из PHP Manual }.
Несмотря на то, что PHP 3 и 4 в определённой степени справлялись с этими трудностями, предоставляя синтаксические ухищрения для передачи объектов по ссылке, они никогда не брались за суть проблемы:
Объекты отличаются от остальных видов значений, следовательно,
объекты должны передаваться по ссылке, если не указано иного.
Когда мы, наконец, убедились, что объекты — действительно создания особые и заслуживают особого поведения, это стало лишь первым шагом. Мы должны были предложить такой способ реализации этого, который не повлияет на остальную семантику PHP и, желательно, не заставит переписывать весь PHP. К счастью, решение пришло в виде луча света, вспыхнувшего над головой Andi Gutmans'а чуть более года назад. Его идея состояла в замене объектов дескрипторами объектов { в оригинале — object handles }. Дескрипторы объектов, по существу, будут числами, индексами в глобальной таблице объектов. Аналогично любым другим видам переменных они будут передаваться и возвращаться по значению. Благодаря этому новому промежуточному уровню, теперь мы будем работать с дескрипторами объектов, а не с самими объектами. В сущности, это означает, что PHP будет вести себя так, будто сами объекты передаются по ссылке.
Давайте вернёмся к Joe и Joanne. Как изменится поведение wed() теперь? Во-первых, $joanne и $joe больше не будут являться объектами, а станут дескрипторами объектов, скажем, 4 и 7 соответственно. Эти целочисленные дескрипторы будут указывать на ячейки в некой глобальной таблице объектов, где находятся настоящие объекты. Когда мы передадим их в wed(), локальные переменные $bride и $groom получат значения 4 и 7; setHusband() изменит объект, на который ссылается 4; setWife() изменит объект, на который ссылается 7; и когда wed() закончит выполнение, $joanne и $joe уже будут проживать первый из своих оставшихся дней совместной жизни.
Таким образом, конец сказки теперь более идиллический, но что это означает для пишущих на PHP? Это означает несколько вещей. Во-первых, это означает, что ваши приложения будут выполняться быстрее, так как будет гораздо меньше операций копирования данных. Например, когда вы передаёте $joe в функцию, вместо необходимости создавать дубликат и копировать его имя, дату рождения, отчество, список прежних адресов, номер соцобеспечения и... что там ещё? – PHP должен передать лишь один дескриптор объекта, одно целое число. Конечно, прямым результатом всего этого также является экономия значительного объёма памяти — хранение целых чисел требует гораздо меньше места, чем хранение всего объекта целиком.
Но, быть может, более важным является то, что новая объектная модель делает объектно-ориентированное программирование на PHP значительно более мощным и интуитивным. Вы больше не должны будете путаться с загадочными символами & для того, чтобы выполнить задачу. Вы больше не должны будете заботиться о том, переживут ли изменения, внесённые вами в объект внутри конструктора, наводящее ужас поведение оператора new. Никогда больше не нужно будет оставаться до двух ночи, отслеживая неуловимые ошибки! Хорошо-хорошо, возможно о последнем я и солгал, но, если серьёзно, новая объектная модель очень значительно уменьшает количество ошибок вида "лови-до-ночи", связанных с объектами. В свою очередь, это означает, что пригодность использования PHP для крупномасштабных проектов становится гораздо легче обосновать.
Как можно было ожидать, Zend Engine 2 содержит довольно много других свойств, согласующихся с его новой объектной моделью. Некоторые из них улучшают объектно-ориентированные возможности, например, приватные члены и методы, статические переменные и агрегирование на уровне языка. Наиболее же значительное — революционный уровень взаимодействия с внешними моделями компонентов, такими как Java, COM/DCOM и .NET посредством перегрузки.
В сравнении с Zend Engine 1 в PHP 4.0, который впервые ввёл этот вид интеграции, новая реализация гораздо быстрее, завершённее, более надёжна и даже легче в поддержке и расширении. Это означает, что PHP 5.0 будет очень хорошо взаимодействовать с вашей системой на основе Java или .NET, так как вы сможете использовать существующие компоненты в PHP явно, как если бы они были обычными PHP-объектами. В отличие от PHP 4.0, который имел специальную реализацию для таких перегруженных объектов, PHP 5.0 использует один и тот же интерфейс для всех объектов, включая родные PHP-объекты. Эта возможность гарантирует, что PHP-объекты и перегруженные объекты ведут себя абсолютно одинаково.
Наконец, Zend Engine 2 также приносит в PHP обработку исключений. До настоящего времени печальной действительностью является то, что большинство разработчиков пишут код, не достаточно изящно обрабатывающий ошибочные ситуации. Не редко встречаются сайты, вываливающие в ваш браузер загадочные ошибки базы данных вместо показа правильно сформулированного сообщения "Произошла такая-то ошибка". В случае с PHP основная причина этого в том, что обработка ошибочных ситуаций — задача, приводящая в уныние; вы, фактически, должны проверять возвращаемое значение для всех и для каждой функции. С добавлением set_error_handler() справляться с этой проблемой стало полегче, так как появилась возможность централизовать обработку ошибок, но до желаемого решения оставалось всё ещё далеко. Добавление же обработки исключений в PHP даст возможность разработчикам отлавливать ошибки более мелким неводом, и, что более важно, поспособствует элегантному восстановлению после ошибок, в каком бы месте программы они ни произошли.
Версия PHP 5.0, основанная на Zend Engine 2.0, ознаменует значительный шаг вперёд в развитии PHP как одной из основных на сегодня web-платформ в мире. Сохраняя свои твёрдые обязательства перед пользователями, предпочитающими использовать функционально структурированный синтаксис PHP, новая версия обеспечит гигантский скачок вперёд для тех, кто заинтересован в его объектно-ориентированных возможностях — особенно для компаний, разрабатывающих крупномасштабные приложения.
Для подготовки данной работы были использованы материалы с сайта http://www.realcoding.net/