SKY / ROOTS /
PHPFAIL1

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

1. Во время начала выполнении кода в деструкторах классов, глобальные переменные (и не только, а видимо все внешние) содержащие указатели на экземпляры этого класса очищаются. Методы и свойства этого класса является уже недоступными для внешних, например функций. Тем не менее, код деструктора выполняется и в нем доступ к своим свойствам и методам имеется. Эту недоработку следует считать серьезной ошибкой PHP. Какой смысл очищать эти указатели ранее, чем пока не закончился код деструктора (вместе со всей освобождаемой памятью, во время overall финиша)? Абсолютно никакого, кроме того требуется доп. логическое ответвление на эту не нужную работу. Также описанная актуальная логика очистки вредит возможностям языка. Пример из SKY Framework: скрипт завершил нормальное выполнение кода по инструкции die; во время "крышевания", после этого выполняется деструктор объекта SKY. Для фиксации факта крышевания, хорошо бы было в X-трассировке (при режиме отладки) сделать отметку. Но функция trace() не является методом класса SKY и не может обращаться к свойствам объекта SKY (только когда выполняется деструктор). Функцию trace() не нужно делать методом класса SKY, так как она чрезвычайно часто используется, требуется короткое имя и способность быть вызванной из любой другой функции без декларации global, т.е:
001
002
003
004
005
006
// так не хорошо:
global $sky;
$sky->trace('Test tracing');
// нужно так:
trace('Test tracing');
 
Для реализации задуманного приходится выдумывать "хитрые костыли" вместо того, чтобы использовать изящное решение.

2. Этот пункт, в некотором роде продолжение первого, но описываемое здесь важно, поэтому дополнительно в BUG-list... В языке имеется несколько попыток сделать своеобразную футер позицию для исполнения футер кода, это: деструкторы объектов, функция register_shutdown_function(), функционал Exception. Все методы представляют кастрированный функционал (странно, почему?). Во время "выхода" на "футер позицию" исполнения кода, то нельзя сделать вывод в браузер, то нельзя сделать дополнения в заголовок HTTP (с пом. функции header()), то объекты не отовсюду доступны. Сама идея "футер позиции" прекрасная, но не реализована нормально ни одним из способов. Вместо кастрированного функционала, следовало бы просто передать нормальное течение скрипта в нужную позицию, а все остальное удобнее было бы контролировать самому программисту и не урезать возможности языка. Наличие деструкторов в классах PHP, скорее всего является наследием классического представления об ООП, но использование кода в них, с классическим назначением (для де-инициализации объекта) чрезвычайно редко используется для серверных скриптов веб-приложений, память текущего thread освобождается автоматически, а параллельные - практически не используются. Хорошо бы было делать то что нужно для пользователей, а не просто, без весомой причины следовать традиции.
опубликовано ENERGY - 31 Oct 2015 18:34 GMT
последнее редактирование - 1 Nov 2015 06:15 GMT
комментировать