php common что это
Php common что это
PHP Common is a PHP library containing a set of common functionality.
Find PHP Common on Packagist:
To use ArrayUtil you need to import it.
To get a value from an array use get :
You can specify a default value in case the key you’re trying to retrieve doesn’t exists:
To get a nested value from an array you can specify a path:
If required, you can use an alternate delimiter:
To set a value or nested value use the set method:
If the key or path not already exist, it will be created.
With insert you can create a new value at a path or key, however, the path will only be created if it does not yet exists.
It’s also possible to delete a key or path:
Or to delete multiple paths or keys at once:
Or with an alternate delimiter:
To test if a key or path exists use:
If you need to prefix all the values in an array, use the prefix method:
If you need to postfix all the values in an array, use the postfix method:
Sometimes you need to «flatten» an array, i.e. glueing the keys and values together with a symbol or character:
Or use a different ‘glue’ character from the default ‘=’:
Returns the keys of an array in the same way the array_keys function works, however, keys allows you to specifiy a prefix:
Returns the values of an array in the same way the array_values function works, however, values allows you to specify a prefix:
Tests if the values of one array exist in another. E.g:
The above tests if the values of the first array (needle) exist in the second array (haystack), which in the above example is true.
Returns a value from an array and deletes the key in the array.
The above example returns the value for foo from the array and deletes the foo key from the array.
About
PHP Common is a PHP library containing a set of common functionality.
Всё, что вы хотели знать о CLI, CGI, MOD, но стеснялись спросить
… Я знаю кун-фу, каратэ, таэквондо и еще много страшных слов!
(с) анекдот
Меня начинающие админы последнее время стали часто спрашивать «А чем отличаются пакеты php-cgi, php-cli и mod_php? И почему, например, для Python есть mod_python, но нет python-cgi?»
Сначала было смешно, но потом стало ясно, что сей вопрос хоть раз да возникал у каждого, кто занимается администрированием LAMP(ссылка) и подобных серверов.
Статья написана по мотивам моей беседы с felvis, поэтому заранее извиняюсь за некоторую вольность изложения.
Пару слов о процессах
Ещё пример, вместо команды env можно выполнить
cat /proc/self/environ
Увидите то же самое, только в менее удобочитаемом виде 🙂
Всё, теперь то что нам нужно для понимания отличий CGI и CLI мы знаем. Идём далее.
Буквы, буквы
поймёте, что имеется ввиду.
Кстати, именно из-за вышеописанного один и тот же скрипт будет работать по-разному из консоли и через браузер. Разработчик, будь внимателен при отладке!
Немного про пакеты
Теперь за Python. Почему есть mod_python, но нет python-cgi и python-cli?
Тут всё просто, проведём аналогию:
Нужно отдельно пояснить, что CGI — это Common Gateway Interface для веб-серверов (не только Апача). То есть CGI — это лишь технология, с помощью которой можно выполнять что угодно, любые бинари, которые формируют веб-страницу (хоть программы на Си писаные — пофиг). В Апаче эту технологию реализует mod_cgi — через этот модуль Апач дёргает скрипт, в котором прописан shebang #!/usr/bin/python или #!/usr/bin/php и тд — и скрипт выполняется.
Основной недостаток mod_cgi — скорость выполнения скриптов, потому-то и пишут отдельные модули для Апача, которые интепретитруют PHP, Python, shell-скрипты — так быстрее.
Конечно есть mod_fcgi, который сильно быстрее mod_cgi — но описание mod_fcgi не входит в рамки этой статьи.
_________
Текст подготовлен в ХабраРедакторе
В тексте использована картинка Binary от Brian «Visual Paradox» Kissinger.
Портируемый php
Введение
Статья про универсальные методы для повышения портируемости php-скриптов. Немного теории, немного практики.
Различия платформ
Любая платформа начинается с файловой системы, поэтому самые важные отличия для php-проектов кроются именно в ней.
Вот так может выглядеть абсолютный путь к файлу в операционной среде Windows
Первая буква обозначает имя логического диска, где расположен файл. Дальше идёт двоеточие и путь к файлу. Сам путь разделён символами обратного слеша (\). Имя диска может быть только одним символом английского алфавита от A до Z. При этом нет никакой разницы между прописными и строчными буквами во всём пути файла.
Практически так же выглядит абсолютный путь к файлу и в UNIX
Вот так может выглядеть структура разделов диска на заурядном UNIX-сервере (FreeBSD):
За разные папки отвечают разные разделы диска, но путь к файлу строится всегда от корня, а не от диска.
Следующим серьёзным отличием двух систем являются права доступа на файлы. В Windows само понятие «права доступа на файл» появилось с приходом NTFS, до этого обходились только атрибутами. Атрибутов у файла может быть несколько и иногда они зависят от самого файла, но есть и стандартный набор:
Таким образом, обычный файл в Windows может быть скрытым, системным, только для чтения, каталогом и для архивирования. Этот набор объясняется тем, что изначально Windows планировалась как однопользовательская система. Когда возникла необходимость в многопользовательской системе и потребовалось разделять доступ к файлам, то эту возможность заложили в файловой системе NTFS. Но использование прав доступа в ней получилось настолько сложным и незаурядным, что их поддержки стандартными функциями в PHP нет.
В UNIX дело обстояло совсем иначе, и права доступа появились ещё на этапе зарождения:
Поскольку PHP разрабатывался для UNIX-систем, то функции для работы с файловой системой были ориентированы в первую очередь на UNIX, их поддержка встроена в стандартный набор функций. Однако, нужно помнить, что права задаются в восьмеричном виде, а это значит, что не надо забывать ставить ноль перед числом с правами, иначе они будут заданы неверно:
Также к критичным различиям можно отнести и локали. Под Windows они используют системные настройки и с ними проблем обычно нет, если проект разрабатывается в той же кодировке, что установлена в системе. Но при работе в UNIX их нужно грамотно выставить, иначе русские буквы могут вести себя крайне неадекватно.
Это далеко не все отличия, которые есть, но они самые опасные. Дальше я наглядно поясню почему.
Различия платформ в примерах
Возьмём простой пример:
Функция pathinfo() разбирает переданный ей путь на составляющие. Двойной обратный слеш используется потому, что в php он является специальным символом экранирования. Проверяем результат выполнения:
Хорошо видно, что в первом случае под Win32 всё отработало нормально. Во втором случае, под Unix, родительский каталог (dirname) определился как текущий (.), а имя файла (basename и filename) определилось вместе со всеми каталогами и диском. Вызвано это как раз тем, что в UNIX обратный слеш не является символом разделения имён файлов и каталогов, а используется для экранирования специальных символов.
Решением проблемы будет замена всех обратных слешей на прямые:
Теперь результат одинаков на обеих платформах. Поскольку PHP уходит корнями в UNIX, то прямой слеш (/) работает в качестве разделителя пути на любой платформе. Во избежание недоразумений лучше всегда и везде использовать только прямой слеш (/) при указании пути к файлу, а также заменять обратный слеш во всех путях, которые пришли извне.
Помимо слешей существует ещё одна серьёзная проблема. Ни для кого не секрет, что многие проекты изначально разрабатываются на компьютерах под управлением MS Windows, поскольку в чём-то она бывает удобней и привычней. И вот на этапе разразботки большого и серьёзного проекта, скажем, возникает необходимость сделать проверку на правильность имени файла. Получилось примерно так:
Так как проект большой и серьёзный, то этот скрипт протестировали на разных платформах:
После того как результаты оказались одинаковы, со спокойной совестью эту функцию поставили в рабочий проект. Через некоторое время эксплуатации проекта на UNIX-сервере пользователи начали жаловаться, что файлы с русскими именами бракуются. Но отдел программистов заявил, что они проверяли и русскоязычные файлы тоже, правда, у себя на сервере. Через несколько проверок прояснилась следующая ситуация:
Подобные ситуации возникают у каждого программиста, который работает только под Windows. Некоторые разработчики не используют специальные множества \w и \W, а указывают диапазоны [_0-9a-zA-Zа-яА-ЯёЁ], что отчасти исправляет ситуацию. Но единственно верным решением будет настройка локалей. Предполагается, что проект разрабатывается в кодировке CP1251, поэтому установка локали может выглядеть примерно так:
После этого регулярные выражения и функции для работы со строками будут работать как часы.
Различия версий php
Несмотря на довольно обширную историю, PHP на сегодняшний день насчитывает три основных ветки: PHP 3, PHP 4 и PHP 5. Ветка PHP 3 уже устарела и больше не поддерживается, PHP 4 подходит к своему финалу, а PHP 5 с продвинутой объектной моделью уверенно заменяет PHP 4.
С приходом новых версий неизбежно возникают проблемы с совместимостью старых программ. При выпуске нового PHP разработчики каждый раз стараются минимизировать все нестыковки, которые могут возникнуть при портировании старых проектов, и у них это хорошо получается. Но есть тонкости, о которых стоит помнить для написания качественных скриптов.
Эти рекомендации помогут уберечь проект от разного рода неожиданностей, связанных с различием веток PHP. Конечно, это не панацея, но иногда помогает.
Различия в конфигурации php.ini
В php.ini находятся все значимые и незначимые настройки для всего, что только есть в PHP. Там присутствуют настройки как для самого PHP, так и для модулей, которые установлены вместе с ним. Трудно найти два хостинг-сервера, у которых бы php.ini совпадал на 100%, зачастую настройки у всех самые разные. Но критическими являются только некоторые из них:
Произвольный код, который был передан через пользовательские данные, был успешно вставлен на страницу. Инъекция удалась! Конечно, можно возразить, что кавычки всё равно в этом скрипте работать не будут, потому что их заэкранируют магические кавычки. Но это будет лишь отчасти правдой. Действительно, в JavaScript есть экранирующий символ, и он даже совпадает с символом из PHP, но в HTML его нет! А значит, используя правила HTML можно сконструировать запрос, который вставит произвольный код с кавычками:
Но самый печальный вариант будет, когда наш PHP-скрипт попадёт на сервер, где магические кавычки отключены:
Но как только экранирование кавычек будет отключено, то появится возможность менять логику, добавляя произвольные команды:
Помимо приветствия выведется также и информация о PHP, но это самое безобидное, что может произойти. Зачастую, через такие «дыры» загружают скрипты-коммандеры, которые работают на стороне сервера, давая злоумышленнику полный доступ к вашему хостингу. Если такой скрипт удастся загрузить, то в любой момент времени атакованный сайт может быть «подправлен» или уничтожен.
Может быть, это, а может быть, ещё что-то побудило разработчиков сделать магические кавычки. Но надо было их делать либо для всех обязательными, либо не делать вовсе. Путаница, которую они вносят, даёт несомненно больший вред для безопасности и портируемости, чем реальной пользы. Но пока они есть, нужно делать следующее:
Правильный пример работы:
short_open_tag
Эта настройка позволяет использовать короткий открывающий тег помимо двух других, и
Настраиваем рабочее окружение для Backend разработки на PHP
За год работы в сфере Web технологий, мне не раз приходилось настраивать своё рабочее окружение. Для новичков не так то просто найти хороший гайд по настройке рабочего окружения.
В этом топике я хочу собрать всё полезное, что возможно пригодится новичкам и хабраюзерам.
Всё это я буду поднимать на Ubuntu 13.04. Предполагается что вы уже скачали её с официального сайт, и установили.
Итак, начнем. Я зайду под root’ом. Если у вас нет такого желания, просто дописывайте во все команды sudo и вводите пароль от системы.
Для начала установим NGINX. Добавим репозиторий проекта NGINX
и добавим туда строки и не забываем сохранять
Скачиваем GPG ключ
Обновляем список пакетов
И наконец устанавливаем NGINX
Для проверки заходим в браузер, в адресной строке пишем localhost и если вы увидели страничку Welcome to nginx! значит вы на верном пути.
И так продолжаем. Устанавливаем PHP-FPM
Теперь нам нужно устранить уязвимости в PHP
Находим там строку
И приводим её к виду
Делаем рестарт PHP-FPM
Изменяем настройки виртуального хоста
Удаляем все старые настройки и вставляем это
Далее нам нужно проверить установился ли php-fpm. Для этого делаем следующее.
В браузере открываем localhost и если вы видите страничку PHP Version значит вы на верном пути
Далее устанавливаем MySQL, вам предложат установить пароль на пользователя root. Установите и запомните его.
Установим memcache. И после его установки перезапустим PHP(service php5-fpm restart)
Теперь на страничке phpinfo нужно найти пункт memcache. Если он есть, значит вы всё еще с нами.
Управление базой из командной строки не всегда удобно. Поэтому мы установим phpMyAdmin
У вас спросят кокой сервер вы ходите использовать, оставляем это поле пустым. Далее вам будет предложено настроить базу для работы сервиса. Сначала вводим пароль для root пользователя, далее для базы данных phpMyAdmin.
Открываем настройку виртуального хоста и вставляем в секцию server < >следущее
В конечном итоге у вас должен получится конфиг вида
Устанавливаем xdebug для отладки наших приложений.
После чего перезапускаем php и ищем на localhost пункт xdebug
Для разработки я использую PHP IDE PhpStorm. Скачать её можно на официальном сайте www.jetbrains.com/phpstorm. Скачиваем и распаковываем в удобную для вас папку. Но для начала нам нужно установить Oracle Java 7.
Добавляем нужный репозиторий и обновляемся
Затем устанавливаем JDK (Java Development Kit)
После установки заходим в папку PhpStorm/bin и запускаем phpstorm.sh, после чего настраиваем IDE.
Теперь настраиваем IDE для работы с xdebug.
Открываем настройки идём в PHP, там выбираем:
PHP Languege level: 5.4
Добавляем интерпритатор: Name php5.4, PHP Home /usr/bin/, Debugger: Xdebug
и в Include path добавляем то что в ковычках: «/usr/share/php«, «.«, «/usr/share/pear»
Далее PHP->Servers нажимаем на + и добавляем сервер.
Name: localhost
Host: localhost
Port: 80
Debagger: Xdebug
И жмём OK.
Далее переходим в PHP->Debug. Находим тут секцию Xdebug и в ней Debug port пишем 9001
Теперь в PHP->Debug->DBGp Proxy и проверяем чтобы порт был 9001 и нажимаем ОК.
Выходи в главное окно и жмём там стрелку вниз и жмём Edit Configurations нажимаем на + и выбираем там PHP Web Aplication. Заполняем настройки:
Name: localhost
Server: выбираем localhost
Browser: Chrome скачанный с google.ru
Теперь нужно настроить php.ini для работы с xdebug
И добавляем в конец файла
Сохраняем. Перезапускаем nginx, php.
Настраиваем Chrome. Настройки->Внешний вид->Всегда показывать панель закладок. У вас должна появится панель закладок. Идём на сайт www.jetbrains.com/phpstorm/marklets и жмём кнопку Generate в разделе Xdebug, Перетаскиваем на панель Start debugger и Stop debugger.
Заходим в PhpStorm, открываем на индексный файл с phpinfo ставим точку останова на строке phpinfo(); и жмем трубку на панеле. После нажатия, верх трубки должен загорется зеленым. Открываем Chrome, заходим на localhost, жмем закладку «Start debugger», обновляем страницу и на мониторе видим PhpStorm с открытой панелью дебага.
На этом мой «небольшой» гайд подошел к концу. Надеюсь он кому то пригодится, кроме как мне.
Всем спасибо, с уважением amstr1k.
Подробно об объектах и классах в PHP
Сегодня объекты используются очень активно, хотя это трудно было предположить после выхода PHP 5 в 2005 году. Тогда я ещё мало что знал о возможностях этого языка. Пятую версию PHP сравнивали с предыдущей, четвёртой, и главным преимуществом нового релиза стала новая, очень мощная объектная модель. И сегодня, десять лет спустя, около 90% всего PHP-кода содержит объекты, не изменившиеся со времени PHP 5.0. Это убедительно говорит о том, какую роль сыграло внедрение объектной модели, неоднократно улучшавшейся на протяжении последующих лет. В этом посте я хотел бы рассказать о том, как всё устроено «под капотом». Чтобы люди понимали суть процессов — почему сделано так, а не иначе — и лучше, полнее использовали возможности языка. Также я затрону тему использования памяти объектами, в том числе в сравнении с эквивалентными массивами (когда это возможно).
Я буду рассказывать на примере версии PHP 5.4, и описываемые мной вещи справедливы для 5.5 и 5.6, потому что устройство объектной модели там почти не претерпело изменений. Обратите внимание, что в версии 5.3 всё не так хорошо с точки зрения возможностей и общей производительности.
В PHP 7, который пока ещё активно разрабатывается, объектная модель переработана не сильно, были внесены лишь незначительные изменения. Просто потому что всё и так хорошо работает, а лучшее — враг хорошего. Были добавлены возможности, не затрагивающие ядро, но здесь об этом речи не пойдёт.
В качестве демонстрации начну с синтетических бенчмарков:
Здесь объявляется простой класс с тремя атрибутами, а затем в цикле создаётся 1000 объектов этого класса. Обратите внимание, как в этом примере используется память: при создании объекта класса Foo и переменной для его хранения выделяется 262 байт динамической памяти PHP.
Давайте заменим объект на эквивалентный массив:
Вот ещё один пример:
Теперь давайте разберём, как всё это устроено в недрах PHP, подкрепив теорией практические наблюдения.
Всё начинается с классов
Внутри PHP класс представляется с помощью структуры zend_class_entry:
Важно знать ещё об одном моменте, связанном с zend_class_entry — о PHP-комментариях. Они также известны как аннотации. Это строковые переменные (в языке С — буферы char* ), которые тоже надо разместить в памяти. Для языка С, не использующего Unicode, в отличие от PHP, правило очень простое: один символ = один байт. Чем больше у вас в классе аннотаций, тем больше памяти будет использовано после парсинга.
У zend_class_entry поле doc_comment содержит аннотации класса. У методов и атрибутов тоже есть такое поле.
Пользовательские и внутренние классы
Пользовательский класс — это класс, заданный с помощью PHP, а внутренний класс задаётся либо благодаря внедрению исходного кода в сам PHP, либо с помощью расширения. Самое большое различие между этими двумя видами классов заключается в том, что пользовательские классы оперируют памятью, выделяемой по запросу, а внутренние — «постоянной» памятью.
Это означает, что когда PHP заканчивает обработку текущего HTTP-запроса, он убирает из памяти и уничтожает все пользовательские классы, готовясь к обработке следующего запроса. Этот подход известен под названием «архитектура без разделения ресурсов» (the share nothing architecture). Так было заложено в PHP с самого начала, и изменять это пока не планируется.
Итак, каждый раз при формировании запроса и парсинге классов происходит выделение памяти для них. После использования класса уничтожается всё, что с ним связано. Так что обязательно используйте все объявленные классы, в противном случае будет теряться память. Применяйте автозагрузчики, они задерживают парсинг/объявление во время выполнения, когда PHP нужно задействовать класс. Несмотря на замедление выполнения, автозагрузчик позволяет грамотно использовать память, поскольку он не будет запущен, пока действительно не возникнет потребность в классе.
С внутренними классами всё иначе. Они размещаются в памяти постоянно, вне зависимости от того, использовали их или нет. То есть они уничтожаются только тогда, когда прекращается работа самого PHP — после завершения обработки всех запросов (подразумеваются веб SAPI, например, PHP-FPM). Поэтому внутренние классы более эффективны, чем пользовательские (в конце запроса уничтожаются только статические атрибуты, больше ничего).
Обратите внимание, что даже при кешировании опкодов, как OPCache, создание и уничтожение класса осуществляется при каждом запросе, как и в случае с пользовательскими классами. OPCache просто ускоряет оба этих процесса.
Как вы заметили, если активировать много PHP-расширений, каждое из которых объявляет много классов, но при этом использовать лишь небольшое их количество, то теряется память. Помните, что PHP-расширения объявляют классы во время запуска PHP, даже если в последующих запросах эти классы использоваться не будут. Поэтому не рекомендуется держать расширения активными, если они не применяются в данный момент, иначе вы будете терять память. Особенно если эти расширения объявляют много классов — хотя они могут забить память и чем-нибудь другим.
Классы, интерфейсы или трейты — без разницы
Не слишком хорошо, что здесь используется 912 байт всего лишь для декларирования интерфейса BarException.
Привязка класса
Многие разработчики не вспоминают о привязке класса, пока не начинают задавать вопросом, а как же всё устроено на самом деле. Привязку класса можно описать как «процесс, в ходе которого сам класс и все связанные с ним данные подготавливаются для полноценного использования разработчиком». Этот процесс очень прост и не требует много ресурсов, если речь идёт о каком-то одном классе, не дополняющем другой, не использующем трейты и не внедряющим интерфейс. Процесс привязки для таких классов полностью протекает во время компиляции, а в ходе выполнения ресурсы на это уже не тратятся. Обратите внимание, что речь шла привязке класса, задекларированного пользователем. Для внутренних классов тот же самый процесс выполняется, когда классы зарегистрированы ядром или расширениями PHP, как раз перед запуском пользовательских скриптов — и делается это лишь один раз за всё время работы PHP.
Всё сильно усложняется, если речь заходит о внедрении интерфейсов или наследовании классов. Тогда в ходе привязки класса у родительских и дочерних объектов (будь то классы или интерфейсы) копируется абсолютно все.
Тут добавить нечего, простой случай.
Для каждой из таблиц функций (методов) используется do_inherit_method :
Что касается наследования, то здесь, в принципе, всё то же самое, что и при внедрении интерфейса. Только вовлечено ещё больше «участников». Но хочу отметить, что если PHP уже знает о классе, то привязка осуществляется во время компилирования, а если не знает — то во время выполнения. Так что лучше объявлять так:
Кстати, рутинная процедура привязки класса может привести к очень странному поведению:
В первом варианте привязка класса В отложена на время выполнения, потому что когда компилятор доходит до объявления этого класса, он ещё ничего не знает о классе А. Когда начинается выполнение, то привязка класса А происходит без вопросов, потому что он уже скомпилирован, будучи одиночным классом. Во втором случае всё иначе. Привязка класса С отложена на время выполнения, потому что компилятор ещё ничего не знает о В, пытаясь скомпилировать его. Но когда во время выполнения начинается привязка класса С, то он ищет В, который не существует, поскольку не скомпилирован по причине того, что В является дополнением. Вылетает сообщение “Class B doesn’t exist”.
Объекты
Итак, теперь мы знаем, что:
Теперь поговорим об объектах. В первой главе показано, что создание «классического» объекта («классического» пользовательского класса) потребовало очень мало памяти, около 200 байт. Всё дело в классе. Дальнейшая компиляция класса тоже потребляет память, но это к лучшему, потому что для создания одиночного объекта требуется меньше байт. По сути, объект представляет собой крохотный набор из крохотных структур.
Управление методами объекта
Вы могли заметить интересную вещь, посмотрите на первые строки:
Во время компиляции функции/метода происходит немедленный перевод в нижний регистр. Вышеприведённая функция BAR() превращается в bar() компилятором при добавлении метода таблице классов и функций.
В приведённом примере первый вызов статический: компилятор вычислил key для строковой “bar”, а когда приходит время вызова метода, ему нужно делать меньше работы. Второй вызов уже динамический, компилятор ничего не знает о “$b”, не может вычислить key для вызова метода. Затем, во время выполнения, нам придётся перевести строковую в нижний регистр и вычислить её хеш ( zend_hash_func() ), что не лучшим образом сказывается на производительности.
Управление атрибутами объекта
Вот что происходит:
Так что, создавая объект, мы «всего лишь» создаём структуру zend_object весом 32 байта:
Далее движок создаёт вектор признаков нашего объекта:
Вероятно, у вас возникли два вопроса:
Пока вы не пишете в объект, его потребление памяти не меняется. После записи он занимает уже больше места (пока не будет уничтожен), поскольку содержит все записанные в него атрибуты.
Объекты, ведущие себя как ссылки благодаря хранилищу объектов
Объекты не являются ссылками. Это демонстрируется на маленьком скрипте:
Все сейчас скажут, что «в PHP 5 объекты являются ссылками», об этом упоминает даже официальный мануал. Технически это совершенно неверно. Тем не менее, объекты могут вести себя так же, как и ссылки. Например, когда вы передаёте переменную, являющуюся объектом функции, эта функция может модифицировать тот же объект.
object(MyClass)#1 (0) < >/* #1 is the object handle (number), it is unique */
Когда мы вызываем метод, движок изменяет область видимости:
Вот так можно получать доступ к приватным членам объектов, не принадлежащим вам, но являющимся дочерними по отношению к вашей текущей области видимости:
Эта особенность стала причиной большого количества баг-репортов от разработчиков. Но так устроена объектная модель в PHP — на самом деле, мы задаём область видимости на основе не объекта, а класса. В случае с нашим классом “Foo”, вы можете работать с любым приватным Foo любого другого Foo, как показано выше.
О деструкторе
Деструкторы опасны, не полагайтесь на них, поскольку PHP их не вызывает даже в случае фатальной ошибки:
А что насчёт порядка вызова деструкторов в том случае, если они всё-таки вызываются? Ответ хорошо виден в коде:
Здесь продемонстрированы три стадии вызова деструктора:
PHP не вызывает деструкторы в случае возникновения какой-либо фатальной ошибки. Дело в том, что в этом случае Zend работает нестабильно, а вызов деструкторов приводит к выполнению пользовательского кода, который может получить доступ к ошибочным указателям и, в результате, к падению PHP. Уж лучше сохранять стабильность системы — поэтому вызов деструкторов и блокируется. Возможно, в PHP 7 что-то и поменяется.
Суммируя вышесказанное: не доверяйте деструкторам критически важный код, например, управление механизмом блокировки (lock mechanism), поскольку PHP может и не вызвать деструктор или вызвать его в неконтролируемой последовательности. Если всё-таки важный код обрабатывается деструктором, то как минимум самостоятельно контролируйте жизненный цикл объектов. PHP вызовет деструктор, когда refcount вашего объекта упадёт до нуля, а это значит, что объект больше не используется и его можно безопасно уничтожить.