PS. Если сделать стены разной высоты в SweetHome3D как на картинке выше, то для программы это будет уже не наклонная стена, а наклонный потолок, и в него уже не вставишь окно.
Я после недолгих поисков остановился на SweetHome3D.
Плюсы:
Возможность задать стороны света при проектировании дома. Полезно при рендере — можно посмотреть, как будут освещаться комнаты в разное время суток (естественным светом, дополнительно можно включать/выключать искуственное освещение);
Виртуальная прогулка по комнатам;
Возможность нарисовать стены обводя заранее импортированный план дома/кваритры;
Возможность импорта 3d-объектов разных форматов.
Единственный для меня существенный минус — нельзя создавать наклонные стены. У вас, как я понял, с этим тоже беда? Ну и вышеперечисленных плюсов при беглом просмотре я тоже не нашёл. Поправьте, если ошибся.
А теперь давайте пример с наследованием, автоматическим экранированием и сандбоксом. Шаблоны компилируются в нативный php, так что оверхед не такой большой, как вам кажется. Если же в вашем приложении шаблоны действительно являются узким местом, попробуйте Си расширение.
Поймите меня правильно, я за то, чтобы использовать @ с умом и крайне осторожно. В 99.9% случаев можно обойтись без подавления. И date(z) как раз тот случай. В то время как подавление ошибки может скрыть куда более серьёзные проблемы. Например, подавление вызова функции, которая поставляется с каким-нибудь расширением. Подавив эту ошибку, может быть очень трудно выявить, что причина некорректной работы приложения в недоустановленном расширении. Не говоря уже о том, что операция подавления не из дешевых.
Касаемо вашего примера:
Зависит от того, чем является удаляемый файл для приложения и как ошибка при удалении повлияет на дальнейшую его работу. В одном случае хватит и @, потому что, по-большому счёту, приложению не важно, удалится этот временный файл или нет, и смысла логировать эту ошибку нет. В другом случае ошибка удаления может быть критической и нарушить дальнейшую логику работы, тогда я бы написал что-то типа:
if (true !== @unlink($file)) {
throw new \RuntimeException(sprintf('Failed to remove file %s.', $file));
}
Но и тут я использовал @ потому, что сообщаю приложению об ошибке посредством исключения и дублировать эту ошибку нет смысла.
Но, всё-таки, сравнение тут unlink($file) и date(z) не совсем корректно — это разного рода ошибки.
По-сути, работа с файлами/ресурсами — это, навероное, единственный пример, где использование @ ещё как-то оправдано, и мне трудно придумать кейс, где бы это было ещё уместно.
То есть вы хотите сказать, что этой проблемы бы не было, если бы логирование в пхп было отключено или все ошибки подавлялись бы @? Как я понимаю, вы логи вебсервера тоже отключаете, они ведь тоже могут вызвать ошибку файловой системы? Ваша приложение тоже ничего не логирует?
Да, я в курсе. Но error_handler с таким же успехом может обрабатывать и ошибки без подавления. А писать обработчик только для того, чтобы обрабатывать подавление @ выглядит извратом.
Код с подавлением ошибок ещё больший говнокод, чем код, генерирующий эти самые ошибки.
Потому как неподавленные ошибки можно не показывать, но логировать. В случае же использования @ вы рискуете провести много весёлых часов/дней/недель, вылавливая баги «неговнокода».
Так что, либо оптимизировать по полной без @, либо писать правильно:
Если мы всё-таки меряем количество символов, то для случая с нотисами и числами самый короткий вариант такой. Чтобы избавиться от чисел можно вставить U+2002 между ?:
А что, по условию задачи нельзя менять дефолтные значения в php.ini? Если да, тогда код
<?=date('z');
тоже будет генерировать ошибку, так как по-умолчанию data.timezone в phi.ini не задан и
Every call to a date/time function will generate a E_NOTICE if the time zone is not valid, and/or a E_STRICT or E_WARNING message if using the system settings or the TZ environment variable.
Тогда наверное нужно уточнить, что ваш код для версии <= 2.0.0beta-1, которая вышла почти год назад. Не пойму, статья была написана в тоже время? Потому как с beta-2 уже нет _sendMail(), a 3 дня назад уже вышел rc7.
P.S. В примерах я использовал Zend Framework 2.0, которая на момент написания статьи ещё находится на стадии бета-тестирования. Если вы работаете с версией 1.*, то нужно переименовать классы ...
Слабое место тут как раз не столько в использовании pure php, сколько в том, что нет никакой обработки критических ситуаций. Например, как уже спрашивалmarkPnk, что будет, если отправка письма вдруг заняла больше минуты? Или что будет, если скрипт умрёт после того как mail() отработала, но запись ещё не удалилась из базы? Или письмо было отклонено почтовым сервером?
Ну а про привязку товаров — рисуйте, что есть в наличии за приемлемые деньги, не вижу в этом проблемы.
Плюсы:
Единственный для меня существенный минус — нельзя создавать наклонные стены. У вас, как я понял, с этим тоже беда? Ну и вышеперечисленных плюсов при беглом просмотре я тоже не нашёл. Поправьте, если ошибся.
layout.html.twig
page.html.twig
Касаемо вашего примера:
Зависит от того, чем является удаляемый файл для приложения и как ошибка при удалении повлияет на дальнейшую его работу. В одном случае хватит и @, потому что, по-большому счёту, приложению не важно, удалится этот временный файл или нет, и смысла логировать эту ошибку нет. В другом случае ошибка удаления может быть критической и нарушить дальнейшую логику работы, тогда я бы написал что-то типа:
Но и тут я использовал @ потому, что сообщаю приложению об ошибке посредством исключения и дублировать эту ошибку нет смысла.
Но, всё-таки, сравнение тут unlink($file) и date(z) не совсем корректно — это разного рода ошибки.
По-сути, работа с файлами/ресурсами — это, навероное, единственный пример, где использование @ ещё как-то оправдано, и мне трудно придумать кейс, где бы это было ещё уместно.
Может всё-таки следовало настроить сервер?
Потому как неподавленные ошибки можно не показывать, но логировать. В случае же использования @ вы рискуете провести много весёлых часов/дней/недель, вылавливая баги «неговнокода».
Так что, либо оптимизировать по полной без @, либо писать правильно:
тоже будет генерировать ошибку, так как по-умолчанию
data.timezone
в phi.ini не задан иdisplay_errors = Off
в php.ini
лайт версия:
Вы уверены что этот код работает в zf2? Что-то я не нахожу public function _sendMail() {… }
в Zend/Mail/Transport/Sendmail.php.