Ну Симфони например это на мой взгляд как раз прям явная попытка перетащить java на php. Как по мне так это дичайший оверхед. Но это всё становится оправданым и радужным, если представить, что с этим "пхп" как раз будет работать джавист. Это сраду всё объясняет.
Симфони просто надо правильно готовить ) Сама по себе она монстр, а вот отдельные её компоненты обычно довольно удобны. Добавлено спустя 8 минут 31 секунду: Статику используют обычно те, кому лень создавать объекты на каждый чих ) Кстати, для таких случаев как у автора довольно удобны такие обертки: https://github.com/laravel/framework/blob/5.1/src/Illuminat ... s.php#L138 С одной стороны мы получаем тот самый удобный синтаксис, с другой не городим непонятной хрени в классах. p.s. автор, добавь к методу get параметр deafult для значения по умолчанию. Удобно )
несомненно, что оно задумано и сделано для ускорения работы и рутинных операций. Просто сам подход симфони он очень явовый, как ни крути. А статик-классы удобны, да. Когда у тебя есть какая-то херня, которая одна точно, и нужна глобально, то даже синглтон не нужен.
Не равняйте php и go, 1 стар и за все время много чего придумали, 2 молод и ждем своего часа. Подождите пару лет, и на го будет много чего интересного и крутого. На го архитектура приложения не такая как на пхп, и к этому нужно привыкнуть, при правильном подходе, он превосходит пхп в много раз.
задачи разные, превосходить он пхп не может, как грузовик не может превосходить велосипед. Пхп идеален для своей задачи. Го прекрасен со своими каналами. Просто не нужно делать на пхп, то, для чего он не подходит. И усё. =)
Многие не понимают этого и пишут на пхп все подряд. Кстати трудно представить для чего го не подойдёт?
подойдет это слишком общий термин. Пхп позволяет лепить сайты быстро и легко. А го позволяет делать куда больше. Но если куда больше не требуется, то хорошо и на пхп.
Если очень много времени, то ассемблер тоже неплох для веба, а проблема в том что даже через два года ситуация не не изменится ) У го другая специализация, он не заточен под веб, в нем нет того огромного количества сахара и инструментов, что есть для этого в пхп и не будет. Го хорош, если вам надо переварить большой объем данных с вычислениями, быстро и не сжирая все имеющиеся ресурсы сервера. Грубо говоря, как сервис, который на вход получит команду/данные и на выходе отдаст результат он крут, да и то не всегда: пхп сейчас и пхп 2-3-4 года назад - это разные пхп. Он уже может работать без необходимости умирать каждый раз, научился чистить за собой мусор и вообще аккуратнее относиться к используемым ресурсам. А количество пакетов с готовой реализаций различных задач превышает все допустимые нормы ) Проблема пыха не в языке, а в тех кто привык писать на нем по старинке, слепо веря в то, что он шаблонизатор. Да и вообще, говорить о том, что один язык однозначно лучше другого вне контекста - глупо.
Статик лучше! Как их ловить предлагаешь? Я ленивый, проще когда ини сам создаётся с нужными параметрами, зашёл исправил что надо и всё.
И чем же он не лучше? Статик производительней. С ним удобней работать. Не надо создавать экземпляры класса. В этом случае он больше подходит, потому что мой класс это тупо набор функций не больше.
try catch - для того они и были придуманы Добавлено спустя 1 минуту 13 секунд: инишки они для человеко-читаемых конфигов. оно не для того, чтобы читать и писать, а для старовых настроек небольших. Вообще, я храню такого типа конфиги маленькие прямо в пхп файлах. Добавлено спустя 1 минуту 27 секунд: статик подходит только тогда, когда не надо создавать разные сущности. по сути это некий набор функций, сгруппированных под общим названием.
Так локализация должна человеком легко читаться и правиться. За чем это? Я просто сделал обработчик исключений - set_exception_handler, и не пользуюсь try/catch.
Глобальные удобные неймспейсы/группы же. Это мало кто понимает, из тех, кто имеет осознание того, что такое пхп и как он работает. И они не городят, как правило.
Пользовался как то, для вордпресс плагина локализацию делал. Не понравилось. Код с try catch: Код (PHP): <?php function inverse($x) { if (!$x) { throw new Exception('Деление на ноль.'); } return 1/$x; } try { echo inverse(0) . "\n"; } catch (Exception $e) { echo 'Поймано исключение: ', $e->getMessage(), "\n"; } Код с set_exception_handler: Код (PHP): <?php set_exception_handler(function ($e) { echo 'Поймано исключение: ', $e->getMessage(), "\n"; }); function inverse($x) { if (!$x) { throw new Exception('Деление на ноль.'); } return 1/$x; } inverse(0); Встаёт вопрос какой лучше? Я использую set_exception_handler, мне он больше нравиться.
ну это смысла лишено. У тебя есть функция. Она возвращает тру при успехе, фалс при неудаче. Этого достаточно. Эксепшн тут не нужно кидать вообще. Его можно если нужно кидать снаружи, если функция вернула фалс. И то по случаю.
так трай-кэтчи можно друг в друга вкладывать, плюс кэтчи могту ловить разные типы эксепшенов в разных местах. Удобно.
а тебе не должно нравится. по является достаточно распространенным инструментом локализации, который компилирует домены и предоставляет к ним практически молниеносный доступ. зачастую еще и оставляя в оперативной памяти. плюс сюда плюральные формы на лету понимает. а твой цирк с ини-файлами для локализации это удобно лично для тебя, но не для системы, которой приходится работать с твоими ини-файлами. возьми тот же самый родной пхп-массив и зенд положит опкод себе в память - профит. локализация в конце концов не так часто меняется чтоб её три раза загружать ради вывода трёх строк в одной обработке запроса. Добавлено спустя 2 минуты 8 секунд: да не, тут всё понятно. ему чем проще тем лучше. положил сверху ловушку исключений и бросается ими спокойно. пусть делает как удобно. научится ещё...
хм... а что не так с исключениями? они обрабатываются внутри, если возможно корректно их обработать, иначе же вполне логично отправлять их наверх. Вплоть до самого верха, где и произойдет локальный апокалипсис )
Распространенный, не значит хороший и подходящий мне. Компилирует домены - Это как? Молниеносный доступ тут явно преувеличил, хотя не знаю. Как нибудь попробую но не сегодня, сегодня у меня на INI работает. Это да)))