Комментарии 17
(недоумевающий взгляд из лагеря питона)
А что, пхп в 2018 году не умеет при смерти показывать стэктрейс?
PHP интерпретатор, в том случае, когда падает PHP-программа — так и делает.
Только в данном случае падал сам интерпретатор, и на консоль при этом выводил только краткое "Segmentation fault (core dumped)".
Сомневаюсь, что какой-либо интерпретируемый язык может как-то иначе.
Если кто не в курсе, то core dump практически однозначное свидетельство наличия бага в коде того процесса, который собственно сдампился. Если крашится процесс php значит ошибка в самом C коде php или используемых им библиотек, пускай даже добраться до неё получается только при наличии ошибки в PHP коде приложения или каких-то битых данных, поданных на вход PHP
На старте «но у меня же нет upstream server» хотя он есть
Внутри — использование reflection для продакшен функционала
По факту — выбрасывание эксепшена в эксепшен хендлере
использование reflection для продакшен функционала
Эм… ну как бы это норма. Любой нормальный DI-контейнер работает на рефлексии (Хоть sf, хоть laravel, хоть php-di. А как иначе-то?). Аннотации (doctrine/annotations) работают на рефлексии. Никто их из продакшена не попёр за это. Да кучу всего интересного можно сделать на рефлексиях. У меня в приложении гидратор самописный тоже этой наркотой балуется.
Ну мне уже коллега в устном разговоре попенял за использование рефлексии в коде сервиса, сказав, что она — сильно медленная штука. И как пример ее уместного использования упомянул как раз про doctrine, где, с использованием аннотаций и рефлексии, генерится PHP-код работы с сущностями. Далее результат кодогенерации кешируется, и после этого рефлексия больше не применяется — до следующего изменения аннотаций. Думаю переделать свой вывод констант с backend в JS по этой же схеме.
Предлагаю самостоятельно проверить скорость работы пары вызовов оной.
В любом случае, кодогенерация — это ещё большее зло. Я бы пристрелил разработчиков доктрины (и контейнера симфони) за это, если бы не понимал, что в их случае — это вполне оправданно.
вот часто это слышу но как-то никогда нет аргументов. Обычно просто пересказ того что говорят другие. при этом другие обычно говорят о том виде кодогенерации, которая не воспроизводима. То есть ты сгенерил код и не можешь его «обновить» перегенерив.
А если у тебя есть DSL по которому генерится код — в чем проблема? это намного лучше чем интерпритация в рантайме банально потому что дебажить такое проще.
вот часто это слышу но как-то никогда нет аргументов. Обычно просто пересказ того что говорят другие. при этом другие обычно говорят о том виде кодогенерации, которая не воспроизводима. То есть ты сгенерил код и не можешь его «обновить» перегенерив.
Я про практику в этом случае. php-deal просто не будет работать с доктриной, как и другие подобные штуки.
А если у тебя есть DSL по которому генерится код — в чем проблема? это намного лучше чем интерпритация в рантайме банально потому что дебажить такое проще.
А DSL уже не код, там АОП не применишь, так что пофигу)
— прямое присваивание значения «статическому» свойству
— прямое присваивание значения динамическому свойству
— присваивание через сеттер
— присваивание через __set
— присваивание через \Closure
— присваивание через рефлексию
Кодогенерация нормальный подход. по сути это лишь компиляция какого-то DSL в исполняемый код.
История одной отладки? О чем статья?
Львы в пустыне и интроспекция