Php не может работать асинхронно вообще! У него это в ядре не предусмотрено. Чтобы понять что такое асинхронность вы должны для начала понять принцип работы той же libevent.
Ололо, не несите чушь. Ничего не мешает php обрабатывать множество запросов в одном потоке с помощью libevent и поддержка ядра тут ни при чем.
Ну почему практически во всех темах про event-driven сервера и фреймворки набегает куча комментаторов, неотличающих тредовую и событийную модели, и начинает нести какую-то ахинею?
Ну раздача статики это как раз тот пример, когда необходимость использования событийной модели ни у кого не вызывает сомнений. А вот что вы будете с этой моделью делать, если у вас при обслуживании клиентов возникают сложные вычисления? Из-за одного тяжелого запроса все остальные клиенты будут ждать.
Как я «люблю» такие конкретные вопросы…
Как по мне — она и так нормальная, но я mercurial использовал раза два и те readonly.
Если ваши use-case'ы системы контроля версий ограничиваются только коммитами и пушами, то, наверное, да, для вас она нормальная. Но как можно пользоваться плагином, в котором нельзя:
— мержить ветки (уже только этого достаточно, чтобы всерьез не рассматривать поделие, которое товарищи из jetbrains гордо именуют поддержкой меркуриала)
— увидеть историю правок (со списком затронутых файлов, я уже на говорю про graphlog). В вашем плагине можно только посмотреть историю конкретного файла.
— увидеть список коммитов, которые будут запушены (я уже не говорю о возможности выборочного пуша коммитов)
— Shelve, Rebase и т.п.
Вы правда считаете это нормальным? Посмотрите на свой же плагин в git'у или на hge для eclipse'а, вот их можно назвать нормальными.
Невозможно отказаться от myErrorHandler потому что он обрабатывает стандартные сообщения php об ошибках (Undefined variable, и т.п.). Придётся в нём продублировать функционал универсальной штуки?
Ну даже если ваш myErrorHandler останется (хотя по-хорошему логику логирования и отправки email'ов следует реализовывать за пределами этой функции), то все равно явный вызов trigger_error будет только в одном месте — на верхнем уровне обработки эксепшенов, который отлавливает только необработанные эксепшены. Приведите пример, где еще может понадобиться явно вызывать trigger_error вместо того, чтобы бросать эксепшены.
Ну если по аналогии с вашим кодом, то, например, так:
<?php
try {
Application::init()
} catch (Exception $e) {
// Универсальная штука,
// которая отправляет мне сообщения
// обо всех не отловленных эксепшенах с трейсами и дампами.
}
Таким образом будут обработаны все не отловленные эксепшены в приложение. И не надо ничего никуда явно перенаправлять
Например, если мой движок не может подключиться к БД, то это ошибка. Всё. Точка. Без БД сайт не работает, и я не могу с этим ничего сделать. Поэтому я вызываю ales_kaput() и trigger_error()
А что вы будете делать, если в будущем вы решите добавить какую-нибудь логику в обработку конкретно этой ошибки? В какое место будете ее вставлять? Будете править логику подключения к БД?
Ололо, не несите чушь. Ничего не мешает php обрабатывать множество запросов в одном потоке с помощью libevent и поддержка ядра тут ни при чем.
А как же PyDev для Eclipse'а?
Это с чего бы вдруг?
Если ваши use-case'ы системы контроля версий ограничиваются только коммитами и пушами, то, наверное, да, для вас она нормальная. Но как можно пользоваться плагином, в котором нельзя:
— мержить ветки (уже только этого достаточно, чтобы всерьез не рассматривать поделие, которое товарищи из jetbrains гордо именуют поддержкой меркуриала)
— увидеть историю правок (со списком затронутых файлов, я уже на говорю про graphlog). В вашем плагине можно только посмотреть историю конкретного файла.
— увидеть список коммитов, которые будут запушены (я уже не говорю о возможности выборочного пуша коммитов)
— Shelve, Rebase и т.п.
Вы правда считаете это нормальным? Посмотрите на свой же плагин в git'у или на hge для eclipse'а, вот их можно назвать нормальными.
Ну даже если ваш myErrorHandler останется (хотя по-хорошему логику логирования и отправки email'ов следует реализовывать за пределами этой функции), то все равно явный вызов trigger_error будет только в одном месте — на верхнем уровне обработки эксепшенов, который отлавливает только необработанные эксепшены. Приведите пример, где еще может понадобиться явно вызывать trigger_error вместо того, чтобы бросать эксепшены.
Таким образом будут обработаны все не отловленные эксепшены в приложение. И не надо ничего никуда явно перенаправлять
У меня для тебя плохие новости, бро.
Тогда приведите более удачные примеры, где, по-вашему мнению, использование trigger_error предпочтительнее исключений
А что вы будете делать, если в будущем вы решите добавить какую-нибудь логику в обработку конкретно этой ошибки? В какое место будете ее вставлять? Будете править логику подключения к БД?
В данном случае это не спутниковые снимки, а аэрофотоснимки