Поэтому я не юзаю KDE. И никогда не буду.

Но, господа, у меня к вам просьба: если нечего сказать окромя того, что у вас работает, — не говорите вы ничего. Не будете казаться идиотами и детьми. К тому же, мне чаще интереснее решение в общем виде, то есть патчить и смотреть код в случае чего лично мне будет не лень. Ага, и патчи ответственному за пакет отправлять — тоже не лень. Это колхоз, а не богадельня. И уж тем более не экскурсия в дурдом, где у некоторых психов что-то не работает. Это стремительно развивающаяся система, ошибки в которой неизбежны.

Долгожданный релиз PHP 5.3 состоялся!

Я тут не так давно пост писал о мудрости и о PHP, в сочетании с ним флоны тут не просто к месту, они тут ломятся по осевой со скоростью километров двести в час. Вот он.

Мне давно хочется обсудить использование событий в приложениях на PHP. Нужно ли? Осмысленно ли? И, если ответ на первые два вопроса утвердительный, то где, в каких случаях? Лично мне кажется, что в событийно-ориентированных приложениях удобно расширять функционал, но они сложны как в проектировании, так и в тестировании. События могут использоваться как дополнительная «фишка» фреймворка, но быть краеугольным камнем, на котором построен весь функционал приложения, они не должны. Причин тому несколько:

1. глядя на диаграммы и на код, мы не видим, что происходит параллельно вызовам тех или иных методов, то есть изменение состояния системы для нас неочевидно;
2. в этой связи нам необходимо очень внимательно добавлять и удалять обработчики событий: повесить два обработчика одного и того же события или не повесить ни одного очень легко, а искать ошибку такого рода очень сложно;
3. сложность проектирования самих классов событий очень велика, так как заставляет в событии размещать всю возможную информацию, которая может понадобиться обработчику; либо нам нужно «вытаскивать» необходимые данные субъекта в обработчике.

Ваши мнения?

Заранее предчувствую ехидный вопрос ко мне. Да, такой опыт я получал сам, вышеизложенное попробовал на своей шкуре. Но есть разница: я писал очень простой фреймворк, который не сильно-то и усложнился за несколько лет. И ещё одна разница: он изначально был заточен на то, чтобы: а) самого фрейма практически не было; б) кода итогового приложения было минимум; в) чтобы больше было задач, которые библиотеками (общеизвестными, хорошо документированными и т.п.) оперативно решаются. Почему так? А потому что мне сразу надо было получить средство, с помощью которого я могу решать как можно больше задач, не меняя своего подхода к процессу разработки, раз; и потому, что мне не хочется много-много стандартных вещей реализовывать самостоятельно, два. А в подавляющем большинстве как CMS, так и фреймворков, подход сугубо противоположный: автор видит картину своего «идеального проекта», которую сначала набрасывает наскоро, а потом, с течением времени, воплощает в жизнь. Лично я уже три года, кажется, тяну и тяну одну идею. Идея одна, реализация в ближайшие дни, скорее всего, возникнет третья по счёту, благо основательный фундамент в виде готового кода и масштабного опыта эксплуатации этой штуки у меня уже есть. Самый смех в том, что приложения останутся практически полностью совместимы.

Начнём-с.

_{P.S. Картинка кликабельна.}

Давайте разберёмся с, казалось бы, одним из фундаментальных понятий в ООП PHP5, а именно с конструкторами и деструкторами, а то, как выяснилось, эта тема не совсем очевидна.

class Test {
    private $_arg = "no arg";
    function __construct($arg) {
        print "I'm constructor: $arg\n";
        $this->_arg = $arg;
    }
    function __destruct() {
        print "I'm destructor: $this->_arg\n";
    }
}
function iLoveExceptions() {
    throw new Exception("Ha ha!");
}
try {
    $a = new Test(iLoveExceptions());
}
catch(Exception $e) {
    print "Exception!!\n";
}

В итоге мы получаем следующий вывод:

I'm destructor: no arg
Exception!!

Почему так происходит?

Начнём с того, что new — оператор, а операндом является класс и параметры для его конструктора. Следовательно, выполнение этого оператора происходит в два этапа:

1. выделение памяти под объект и инициализация значений его полей по умолчанию;
2. инициализация объекта при помощи конструктора (если таковой имеется).

В данном случае до второго шага мы не доходим, так как исключение вылетает до начала инициализации объекта (то есть между первым и вторым этапами), в момент подготовки параметров конструктора.
Далее мы видим, что деструктор вызывается до обработки исключения. Тоже правильно: на объект не осталось ссылок и он становится интересен сборщику мусора. Заметим: не каждый вызов деструктора предваряется вызовом конструктора.

Естественно, после вылетевшего эксепшна переменная $a остаётся равна NULL, так как до присваивания дело ещё не дошло.

У меня плавно отвалилась челюсть. Не, я понимаю, что маркетинг и все дела, но вообще-то в голове у меня сложилось устойчивое впечатление, что опытные программисты в основном валят с PHP любой версии из-за его неконсистентности — туда, где ход проектов хорошо прогнозируется, где работают в массе своей такие же опытные программисты, ну и так далее, и тому подобное. А вот что может пользоваться спросом тренинг для опытных программистов, каждый из которых, по идее, может за несколько дней прочесть документацию и начать на PHP работать — если, конечно, не побрезгует, и если, конечно, сочтёт это направление работы достаточно денежным (сравним средние зарплаты программиста на PHP и программиста на Java, скажем), — это мне как-то в голову не приходило, да и сейчас не очень в ней укладывается. Скажите мне, пожалуйста, люди добрые, зачем опытному программисту нужен PHP? Что тогда это вообще за такое мифическое понятие — опытный программист? Которому нужен платный тренинг, чтобы освоить язык, на котором худо-бедно дети начинают писать за неделю?

В общем, я в прострации.

Я понимаю, что можно учить опытного программиста, который всю жизнь писал системные утилиты или какие-нибудь бухгалтерские программы, веб-программированию как таковому. То есть объяснять, что такое HTTP, что это протокол без сохранения состояния, что есть только эмуляция засчёт кук и/или сессий, объяснять про языки разметки, про виды веб-серверов, про то, чем отличаются десктопные приложения от веб-приложений. Но. Если человек всё это знает, то чему можно “ускоренно учить” на таком тренинге — я теряюсь в догадках.

[tag]PHP[/tag]

Убей Бог, не помню, кидал ли я в блог ссылку на эту публикацию или нет, но для подавляющего большинства знакомых мне программистов на PHP это чистой воды must read, must understand & must use в одном флаконе. Флакон небольшой, можно принять залпом, а затем перечитать.

Вот эта публикация.

Кстати, возможно, её прочтение излечит молодых программистов от гордых заявлений: “Я похачил XXX!!!” Лично я подобные высказывания и формулирую иначе, и тяжёлым вздохом сопровождаю. Иногда действительно приходится хачить, но это отнюдь не показатель ни моей квалификации, ни качества проекта. “Пришлось…” — и очи долу.