Где-то месяца 3-4 назад я тоже так думал а потом начал загоняться по всяким там возможностям выводить типы, верифицировать запрос (даже по частям) на соответствие схеме без необходимости запуска оного, вопросы композиции запросов (открыл для себя парочку вариантов на тупой конкатенации которые интереснее и удобнее чем то что предлагает большинство билдеров, через под запросы естественно). Ну и т.д.
Что до абстракций типа ORM, репозиториев и критерий — все это прекрасно работает опять же в ситуации когда у тебя все выборки можно влипить в WHERE. без джойнов, подзапросов и прочих оконных функций. Чуть сложнее и абстракции эти перестают помогать (в том виде в котором они существуют в PHP) что опять же ставит вопрос «а нафига оно все надо!?» Ведь взять ту же доктрину (как бы я ее не любил) но на ее изучение нужно немало времени, в ней полно багов, это очень сложный продукт сам по себе… и тот факт что оно помогает мне только для очень простых задач меня очень расстраивает.
ну у вас еще тип есть, который неплохо дополняет какое-то общее $error или $event. Опять же в этом случае нет смысла в суффиксах для типов (InvalidArgumentException вместо InvalidArgument).
Ну так может тогда не нужно пытаться делать инструменты общего назначения и обобщать логику так что бы вышла магента? Что бы "для всех подходила". Причем без должной декомпозиции вы рано или поздно упретесь в количество зависимостей.
чтобы при открытии node_modules глаза на лоб не лезли.
Лайфхак — не открывайте их просто. Это нужно очень редко и главное что бы была возможность удостовериться что пакеты никто не подменил (по подписи) и что нет секьюрити ишусов у зависимостей. Сегодня это делается автоматически.
я говорил про декомпозицию а не про желание обобщить все и вся. Это разные вещи.
По поводу проблем с "форками" — обычно это как раз таки проблема излишнего обобщения. Маленькие узко специализированные решения с меньшей долей вероятности нужно будет "допиливать", их проще заменять полностью. Увы у большинства философия "запихнем в эту простую штуку все".
еще раз — у меня есть маленький пет проджект — SQL парсер на комбинаторах парсеров (игрался с ними), и там доля вызовов функций в целом значительная. Еще у меня был пет проджект — re2php, типа компиляция регулярных выражений в php код (что бы за линейное время разбирать жирные строчки ну и просто прошариться в NFA->DFA). И там вызовов функций было много, очень много (всякие `ord` и т.д.). И там оверхэд от вызова метода чувствуется и можно выжать дополнительно 5-10% (банальный пример — попробуйте реализовать mb_strlen на чистом php и померяйте)) Зачем это делать? Потому что есть специфические задачи когда надо парсить много и «юникод» там в определенных местах, а в большинстве мест хочется все делать за O(1).
Вы когда говорите что «не нужно все это», вы уточняйте что помимо мизерного эффекта на реальный код, нужно еще мизерное количество усилий для того что бы эту оптимизацию выполнять.
Я не говорю что все всегда должны эту оптимизацию делать — это не так. Но обвинять в микрооптимизациях тех, кто просто в php-cs-fixer поставил опцию в том что они тратят свое время на что-то бесполезное я бы не стал.
вам не предлагают null, вам предлагают `Optional`, это чуть-чуть другое, и в целом это дело позволяет вам определить вариант проверить были ли ошибки или нет.
Ну и опять же, лично мне нравится вариант go с явным разделением на «ошибки» и «исключения» (panic).
дальше основной проблемой становится невозможность в php описать ни maybe/optional ни туплы аля го. И остаются только исключения. Которые становятся проблемой если у вас control flow на них завязан.
В «джаве» вы обязаны объявить все исключения которые вы «прокидываете» выше и не обрабатываете. Потому там ситуация чуть-чуть отличается от ситуации в php.
Ну и «отдельный метод» — понятия не имею о чем вы.
Ну как бы JIT как раз поможет, поскольку он может использовать информацию доступную в рантайме (кто-то объявил такую-то функцию) для оптимизаций. Ну это все так, пустые разговоры)
На вызовы функций приходится 0.000...% общего времени исполнения кода.
Никак не буду мерить :)
ну как-то так наша дискуссия сейчас идет.
Во первых у вас возможно 0.0001% а у меня 10% (комбинаторы парсеров, очень простые функции, их много, и они оч много выполняются). Потому что бы сделать более честный бенчмарк и меряют оверхэд от фолбэка в глобальный неймспейс а не "реальное приложение", далее ваша задача экстраполировать результаты данного бенчмарка на свой код, и прикинуть будет профит или можно забить. У некоторых например за счет этого фолбэка на глобальный неймспейс работают подмены функций в тестах)
Во вторых, если эта "оптимизация" требует от меня лишь включить еще один фиксер в php-cs-fixer — я не вижу вообще никакой причины обсуждать "бесполезность" таких вещей. И нет, "пририсовывать палочки" не обязательно — можно сделать явные use function, причем все это не руками а автоматически.
p.s. просто что бы вас как-то попугать. Если в системе будет эксплойт, и там будет возможность как-то подсунуть свой код на сервере — я легко могу сделать так что бы у вас в системе была подменена реализация функции password_hash какая-нибудь. Но это так, страшилки и пугалки. Мы ж не на вордпрессах пишем.
еще раз — на «реальном» приложении все будет зависеть от количества вызовов методов для операций. У подавляющего большинство нет таких проблем и там будет копеешный выйгрыш, а если вы делаете какой-нибудь парсер SQL-я или там graphql-я то там выйгрыш может быть существенный (за счет большого количества вызовов).
Проблема «мерять на реальном приложении» в том, что реальных приложений много разных. А померять стоимость вызова пустого метода двумя способами легко и просто, а дальше уже разработчик «реального приложения» может банально прикинуть актуальна ему эта проблема или нет (если у него за запрос всего пара сотен вызовов функций — ему не надо париться, а если у него пара миллионов вызовов на операцию — заморочаться можно).
Понятнее объясняю причины для такого способа измерений?
ну вопервых такие обсуждения были, а во вторых — я больше про всякие JIT и префетчинги, которые могут это дело учитывать что бы невилировать проблемы с производительностью.
Доктрина, симфони. У меня были проекты где для бизнес логики нужно было много много вызовов функций простых делать (там рекурсивно дерево рефералов обходилось + чуть-чуть математики простой) и там такие вот "микро" оптимизации могли дать еще +10%. Были так же проекты где надо было класстеризовать точки, но это все единичные случаи конечно. А вот на инфраструктурных вещах профит может быть солидный.
а как еще вы можете померять оверхэд при вызове методов/функций?
Да, для вашего проекта и вашего кода возможно профита никакого. Для фреймворков — профит будет, как и для библиотек инфраструктурных. Банально потому что там все чуть посложнее может быть.
Опять же, я не вижу никакой проблемы поскольку такие вот "оптимизации" выполняются автоматически. Возможно в 8-ой версии пыха эта проблема с фолбэком в глобальный нэймспейс уже будет не актуальна.
с npm проблема только одна — разработчики npm-а которые… ну я могу долго тут их ругать за то что у них странные приоритеты и странное отношение к понятию lock файл. Но главный их косяк — отсутствие возможностти подписывать пакеты, дабы исключить возможность подмены как это случалось не однократно (что приводило к веселым новостям о том что eslint слил чьито ключи в сеть).
Что до "сделай мало но хорошо" — посмотрите на штуки типа grep, less и т.д. Я не могу сказать что они мало делают. Ну то есть… проблема этого "мало" в том что это относительное понятие и оно для каждого свое.
Суть не в том что бы там чего-то было "мало" или "много" а в том, что бы причины для изменений штуки были одни и те же. Если причины разные — рано или поздно они начнут конфликтовать между собой и придется идти на компромисы. так магенты появляются (там еще избыточное обобщение и неверная стратегия "расширяемости" в стиле вротпресса).
ходят легенды что изначально план был дать возможность людям дробить проекты на кернелы, потому была папка app и src. В этом случае удобно было бы отдельные модули подключать в свои кернелы бандлами и т.д.
Люди неправильно поняли и начали воспринимать бандлы как модули. и дробить проект именно таким образом. Причина для этого очень и очень проста — автоконфигурация. Вы создали папку Entity внутри бандла и доктрина автоматически подтянула оттуда сущности. Вы создали папку Resources и… ну вы поняли идею.
Жить без бандлов вообще можно было в целом с самого начала. Но ключевой момент распространенных заблуждений — автоконфигурация и неудобные конфиги.
С выходом symfony 3.3 по сути конфиги симфони стали куда более удобны для "безбандальной структуры". Но проблема того, что люди структурируют проект под автоконфигурацию, все еще никуда не делась.
что до мануалов — best practice симфони появился с выходом symfony 2.8 вроде, то есть люди уже успели набомбить проектов и привыкнуть. В этом бэст практис покрывался вопрос что нет смысла дробить на бандлы но опять же автоконфигурация а потому "если хотите бандл — не делите ничего а юзайте AppBundle".
Что до абстракций типа ORM, репозиториев и критерий — все это прекрасно работает опять же в ситуации когда у тебя все выборки можно влипить в WHERE. без джойнов, подзапросов и прочих оконных функций. Чуть сложнее и абстракции эти перестают помогать (в том виде в котором они существуют в PHP) что опять же ставит вопрос «а нафига оно все надо!?» Ведь взять ту же доктрину (как бы я ее не любил) но на ее изучение нужно немало времени, в ней полно багов, это очень сложный продукт сам по себе… и тот факт что оно помогает мне только для очень простых задач меня очень расстраивает.
ну у вас еще тип есть, который неплохо дополняет какое-то общее
$errorили$event. Опять же в этом случае нет смысла в суффиксах для типов (InvalidArgumentExceptionвместоInvalidArgument).Ну так может тогда не нужно пытаться делать инструменты общего назначения и обобщать логику так что бы вышла магента? Что бы "для всех подходила". Причем без должной декомпозиции вы рано или поздно упретесь в количество зависимостей.
Лайфхак — не открывайте их просто. Это нужно очень редко и главное что бы была возможность удостовериться что пакеты никто не подменил (по подписи) и что нет секьюрити ишусов у зависимостей. Сегодня это делается автоматически.
я говорил про декомпозицию а не про желание обобщить все и вся. Это разные вещи.
По поводу проблем с "форками" — обычно это как раз таки проблема излишнего обобщения. Маленькие узко специализированные решения с меньшей долей вероятности нужно будет "допиливать", их проще заменять полностью. Увы у большинства философия "запихнем в эту простую штуку все".
Greg Young — Stop Over-Engenering — может быть вам понравится, весело задорно и в целом пересекается с темой нашего разговора.
Вы когда говорите что «не нужно все это», вы уточняйте что помимо мизерного эффекта на реальный код, нужно еще мизерное количество усилий для того что бы эту оптимизацию выполнять.
Я не говорю что все всегда должны эту оптимизацию делать — это не так. Но обвинять в микрооптимизациях тех, кто просто в php-cs-fixer поставил опцию в том что они тратят свое время на что-то бесполезное я бы не стал.
можете раскрыть мысль? Что значит "со здравым смыслом"?) Мы либо как-то по разному "декомпозицию" понимаем, либо я не знаю.
Ну и опять же, лично мне нравится вариант go с явным разделением на «ошибки» и «исключения» (panic).
дальше основной проблемой становится невозможность в php описать ни maybe/optional ни туплы аля го. И остаются только исключения. Которые становятся проблемой если у вас control flow на них завязан.
Ну и «отдельный метод» — понятия не имею о чем вы.
Потому что в php нет дженериков?
Можно еще вот так:
но это так, для тех кто хочет проникнуться Go
ну как-то так наша дискуссия сейчас идет.
Во первых у вас возможно 0.0001% а у меня 10% (комбинаторы парсеров, очень простые функции, их много, и они оч много выполняются). Потому что бы сделать более честный бенчмарк и меряют оверхэд от фолбэка в глобальный неймспейс а не "реальное приложение", далее ваша задача экстраполировать результаты данного бенчмарка на свой код, и прикинуть будет профит или можно забить. У некоторых например за счет этого фолбэка на глобальный неймспейс работают подмены функций в тестах)
Во вторых, если эта "оптимизация" требует от меня лишь включить еще один фиксер в php-cs-fixer — я не вижу вообще никакой причины обсуждать "бесполезность" таких вещей. И нет, "пририсовывать палочки" не обязательно — можно сделать явные
use function, причем все это не руками а автоматически.p.s. просто что бы вас как-то попугать. Если в системе будет эксплойт, и там будет возможность как-то подсунуть свой код на сервере — я легко могу сделать так что бы у вас в системе была подменена реализация функции
password_hashкакая-нибудь. Но это так, страшилки и пугалки. Мы ж не на вордпрессах пишем.Проблема «мерять на реальном приложении» в том, что реальных приложений много разных. А померять стоимость вызова пустого метода двумя способами легко и просто, а дальше уже разработчик «реального приложения» может банально прикинуть актуальна ему эта проблема или нет (если у него за запрос всего пара сотен вызовов функций — ему не надо париться, а если у него пара миллионов вызовов на операцию — заморочаться можно).
Понятнее объясняю причины для такого способа измерений?
не лень если в строке будут встречаться одинарные кавычки или нужна интерполяция строк.
Доктрина, симфони. У меня были проекты где для бизнес логики нужно было много много вызовов функций простых делать (там рекурсивно дерево рефералов обходилось + чуть-чуть математики простой) и там такие вот "микро" оптимизации могли дать еще +10%. Были так же проекты где надо было класстеризовать точки, но это все единичные случаи конечно. А вот на инфраструктурных вещах профит может быть солидный.
а как еще вы можете померять оверхэд при вызове методов/функций?
Да, для вашего проекта и вашего кода возможно профита никакого. Для фреймворков — профит будет, как и для библиотек инфраструктурных. Банально потому что там все чуть посложнее может быть.
Опять же, я не вижу никакой проблемы поскольку такие вот "оптимизации" выполняются автоматически. Возможно в 8-ой версии пыха эта проблема с фолбэком в глобальный нэймспейс уже будет не актуальна.
с npm проблема только одна — разработчики npm-а которые… ну я могу долго тут их ругать за то что у них странные приоритеты и странное отношение к понятию lock файл. Но главный их косяк — отсутствие возможностти подписывать пакеты, дабы исключить возможность подмены как это случалось не однократно (что приводило к веселым новостям о том что eslint слил чьито ключи в сеть).
Что до "сделай мало но хорошо" — посмотрите на штуки типа grep, less и т.д. Я не могу сказать что они мало делают. Ну то есть… проблема этого "мало" в том что это относительное понятие и оно для каждого свое.
Суть не в том что бы там чего-то было "мало" или "много" а в том, что бы причины для изменений штуки были одни и те же. Если причины разные — рано или поздно они начнут конфликтовать между собой и придется идти на компромисы. так магенты появляются (там еще избыточное обобщение и неверная стратегия "расширяемости" в стиле вротпресса).
ходят легенды что изначально план был дать возможность людям дробить проекты на кернелы, потому была папка
appиsrc. В этом случае удобно было бы отдельные модули подключать в свои кернелы бандлами и т.д.Люди неправильно поняли и начали воспринимать бандлы как модули. и дробить проект именно таким образом. Причина для этого очень и очень проста — автоконфигурация. Вы создали папку
Entityвнутри бандла и доктрина автоматически подтянула оттуда сущности. Вы создали папкуResourcesи… ну вы поняли идею.Жить без бандлов вообще можно было в целом с самого начала. Но ключевой момент распространенных заблуждений — автоконфигурация и неудобные конфиги.
С выходом symfony 3.3 по сути конфиги симфони стали куда более удобны для "безбандальной структуры". Но проблема того, что люди структурируют проект под автоконфигурацию, все еще никуда не делась.
что до мануалов — best practice симфони появился с выходом symfony 2.8 вроде, то есть люди уже успели набомбить проектов и привыкнуть. В этом бэст практис покрывался вопрос что нет смысла дробить на бандлы но опять же автоконфигурация а потому "если хотите бандл — не делите ничего а юзайте AppBundle".