А каким образом чтение метаданных/аспектов/декораторов, созданных в большинстве кейсов для чтения из внешней среды, нарушает инкапсуляцию? Или вы собираетесь читать рефлексию только в рамках тех классов где она описана? Тогда получите даже не то что тесную, а скорее неловкую связанность.
По поводу скорости исполнения и рефлексии — никогда тут не понимал — что и с чем вы сравниваете? Исполнение скрипта с рефлексией и без? Ну очевидно, что первое будет быстрее, второе медленнее. Помимо, на гитхабе много gist-заметок, в которых будет видно, что с ростом версии интерпретатора бенчмарки по использованию рефлексии менялись.
Стоит отметить, что такой вид аттрибутов, хоть и не серебрянная пуля, но отлично ложится в opcache, даже несмотря на то, что в нём дозволили ограниченно использовать выражения. Если не понравится рефлексия + opcache, то в своём юзерленд хендлере можете хоть по файликам раскладывать, не используя после первого прогрева рефлексию в рантайме. К тому же, можно сейчас смело пойти и накатать пару RFC и про custom handler (хотя не представляю зачем он) и про встроенный в язык AnnotationReader, ну или хотя бы сделать вброс в externals — до выпуска восьмёрки времени ещё полно.
А что не так с чтением средствами рефлексии? Даже если глянуть на то, как оно в c# работает, то всё что связанно с атрибутами находится в нэймспейсе "System.Reflection" — в пхп же появятся пользовательские библиотеки/psr-стандарты и сделают те же DeveloperAttribute/Attribute.GetCustomAttributes, которые скроют данную рутину под капот. К тому же, как мне кажется, произвольному процессингу место в исключительно юзерленде, а не в php core — всем и сразу не угодишь, и это наглядно видно, если глянуть как эволюционировали rfc, и краем глаза проглядеть связанные трэды на externals связанные с аннотациями/аттрибутами.
Мне кажется речь не совсем о том, что присутствует или не присутствует в вашем фреймворке(все понимают, через composer можно прикрутить что угодно), а речь о том, что тесты надо было демонстрировать хотя бы с загрузкой сервис-провайдеров/бандлов, с чтением конфигурации, заполнением контейнера зависимостей или сервис-локатора минимально необходимыми компонентами — сделать тот же "hello world", но включая минимальный набор того, что действительно понадобится во время разработки. Я почему-то уверен, что вы взяли тот же laravel и не выпиливали из него сервис-провайдеры, которые не будут использоваться(бродкасты, авторизация, вьюхи, сессии, очереди, dbal и.т.п), не отключали искоробочные глобальные middleware и прочее. Я не говорю, что оно сразу в одном вырастет, а в другом резко просядет, однако результаты будут немного справедливее, чем наблюдается сейчас… Отсюда и такие поспешные выводы про фрэймворк для "hello world".
Ну это, как всегда, странно пинать глобальную область видимости — она есть в языке как данность и всё тут. Если даже абстрагироваться от фреймворков и прикинуть, что вы собрали свою мини-подделку, например из головы, или же из того, что нашлось на просторах packagist, — ваша глобальная видимость, по идее, заканчивается на запуске приложения/каркаса/фреймворка — эта точка, где ваше приложение переезжает вариться в вереницы обьектов, которые изолированы от глобальной области видимости, в которую можно вернуться назад только средствами ключевого слова global.
Пример про то, что "неудобно использовать Dependency Injection" явно демонстрирует ваше неполное понимание того, как готовить такую архитектуру и опять же вызывает вопрос, который, вы, словно, специально опускаете, — с чего вдруг они (база данных | пользователь) должны быть в глобальной области, а не прокидываться куда/когда надо? Если бы вы сами не выкидывали обьекты в глобальную область для чтения позже, то не нужно было бы даже и статью писать, наверное… Да и опять же… Если не сильно грешить, то можно такие вещи, которые вы привели в пример, оформить как singleton, если уж так приспичило куда-то зачем-то лазить, вместо того, чтобы принимать то, что требуется.
В современных это каких? Вот laravel это современный фреймворк? — вы наблюдали как он конфиги грузит и какого они формата? грузит через автолоад? через композер? а кэширование некоторыми фреймворками yaml/xml файлов в php формат, подтягивается как-то иначе?
А то получается, как-то вы вместо того, чтобы рассматривать "современный" код, на который сами так делаете акцент, в.т.ч. указывая на "старые" библиотеки, — вы посмотрели только то, как "современный" код выглядит в вашем приложении, словно это такая вещь в себе, не содержащая исходников и никогда не ссылающаяся на код вне классов.
Речь идёт ведь и о том, что и относительный путь и абсолютный пройдут через real path cache — будь то autoload, будь то простой include/require — под капотом вы будете иметь разжёванный в реальный путь симлинк, который отстаёт от реального мира на X-сконфигурированное время. При чём тут тенденции и какая разница какой путь — я вообще не пойму...
А по вашему "автолоадеры", что под капотом подключают файлы не иначе как через include/require конструкции, не столкнуться с проблемой такого рода? А что, вдруг, не так с "инклюдами" по путям? — или есть какой-то иной способ подтянуть файл, содержащий не класс? а с какой строчки начинается подключение того же composer в проекте?
Express скорее справедливо сравнивать с http микро-фреймвормами — у них есть микрокаркас приложения / http kernel, прослойка middleware, роутер, возможно какой-нибудь di-контейнер. Так что думаю, что корректнее будет его сравнивать с фремворками Slim, Silex, возможно Lumen, но никак ни Laravel/Symfony/ZF.
Странно, что так много комментирующих столь яро критикуют статью. Статья наглядно демонстрирует, что способов избежать использования синглтона более чем полно, особенно если заранее продумать всю архитектуру компонентов.
Хотелось бы сказать в защиту статьи, что синглтон считается антипаттерном не потому, что он ломает SOLID или ещё какие принципы, не дающие спать занудам-перфекционистам, а потому что даёт возможность обращаться к этому единичному инстансу из любой точки кода. Это и создаёт неприятные моменты, как минимум в коде начинающих программистов: вместо минимизации обращений к объекту через метод MySingleton::getInstance() и передачи MySingleton $instance в качестве параметра в востребованный конструктор/метод, его сразу вызывают напрямую из любого места в коде, ведь так можно — это вроде как статика, да и паттерн это позволяет делать, — отсюда и вытекают основные сложности с тестированием, с тем, что это трудно "замокать"/подменить.
А каким образом чтение метаданных/аспектов/декораторов, созданных в большинстве кейсов для чтения из внешней среды, нарушает инкапсуляцию? Или вы собираетесь читать рефлексию только в рамках тех классов где она описана? Тогда получите даже не то что тесную, а скорее неловкую связанность.
По поводу скорости исполнения и рефлексии — никогда тут не понимал — что и с чем вы сравниваете? Исполнение скрипта с рефлексией и без? Ну очевидно, что первое будет быстрее, второе медленнее. Помимо, на гитхабе много gist-заметок, в которых будет видно, что с ростом версии интерпретатора бенчмарки по использованию рефлексии менялись.
Стоит отметить, что такой вид аттрибутов, хоть и не серебрянная пуля, но отлично ложится в opcache, даже несмотря на то, что в нём дозволили ограниченно использовать выражения. Если не понравится рефлексия + opcache, то в своём юзерленд хендлере можете хоть по файликам раскладывать, не используя после первого прогрева рефлексию в рантайме. К тому же, можно сейчас смело пойти и накатать пару RFC и про custom handler (хотя не представляю зачем он) и про встроенный в язык AnnotationReader, ну или хотя бы сделать вброс в externals — до выпуска восьмёрки времени ещё полно.
А что не так с чтением средствами рефлексии? Даже если глянуть на то, как оно в c# работает, то всё что связанно с атрибутами находится в нэймспейсе "System.Reflection" — в пхп же появятся пользовательские библиотеки/psr-стандарты и сделают те же DeveloperAttribute/Attribute.GetCustomAttributes, которые скроют данную рутину под капот. К тому же, как мне кажется, произвольному процессингу место в исключительно юзерленде, а не в php core — всем и сразу не угодишь, и это наглядно видно, если глянуть как эволюционировали rfc, и краем глаза проглядеть связанные трэды на externals связанные с аннотациями/аттрибутами.
Не усмотрел, что вы уже давали ссылку в комментариях. Laravel действительно раздет до косточек, всё стало нагляднее и вопросы отпали, спасибо!
Мне кажется речь не совсем о том, что присутствует или не присутствует в вашем фреймворке(все понимают, через composer можно прикрутить что угодно), а речь о том, что тесты надо было демонстрировать хотя бы с загрузкой сервис-провайдеров/бандлов, с чтением конфигурации, заполнением контейнера зависимостей или сервис-локатора минимально необходимыми компонентами — сделать тот же "hello world", но включая минимальный набор того, что действительно понадобится во время разработки. Я почему-то уверен, что вы взяли тот же laravel и не выпиливали из него сервис-провайдеры, которые не будут использоваться(бродкасты, авторизация, вьюхи, сессии, очереди, dbal и.т.п), не отключали искоробочные глобальные middleware и прочее. Я не говорю, что оно сразу в одном вырастет, а в другом резко просядет, однако результаты будут немного справедливее, чем наблюдается сейчас… Отсюда и такие поспешные выводы про фрэймворк для "hello world".
Ну это, как всегда, странно пинать глобальную область видимости — она есть в языке как данность и всё тут. Если даже абстрагироваться от фреймворков и прикинуть, что вы собрали свою мини-подделку, например из головы, или же из того, что нашлось на просторах packagist, — ваша глобальная видимость, по идее, заканчивается на запуске приложения/каркаса/фреймворка — эта точка, где ваше приложение переезжает вариться в вереницы обьектов, которые изолированы от глобальной области видимости, в которую можно вернуться назад только средствами ключевого слова global.
Пример про то, что "неудобно использовать Dependency Injection" явно демонстрирует ваше неполное понимание того, как готовить такую архитектуру и опять же вызывает вопрос, который, вы, словно, специально опускаете, — с чего вдруг они (база данных | пользователь) должны быть в глобальной области, а не прокидываться куда/когда надо? Если бы вы сами не выкидывали обьекты в глобальную область для чтения позже, то не нужно было бы даже и статью писать, наверное… Да и опять же… Если не сильно грешить, то можно такие вещи, которые вы привели в пример, оформить как singleton, если уж так приспичило куда-то зачем-то лазить, вместо того, чтобы принимать то, что требуется.
В современных это каких? Вот laravel это современный фреймворк? — вы наблюдали как он конфиги грузит и какого они формата? грузит через автолоад? через композер? а кэширование некоторыми фреймворками yaml/xml файлов в php формат, подтягивается как-то иначе?
А то получается, как-то вы вместо того, чтобы рассматривать "современный" код, на который сами так делаете акцент, в.т.ч. указывая на "старые" библиотеки, — вы посмотрели только то, как "современный" код выглядит в вашем приложении, словно это такая вещь в себе, не содержащая исходников и никогда не ссылающаяся на код вне классов.
Речь идёт ведь и о том, что и относительный путь и абсолютный пройдут через real path cache — будь то autoload, будь то простой include/require — под капотом вы будете иметь разжёванный в реальный путь симлинк, который отстаёт от реального мира на X-сконфигурированное время. При чём тут тенденции и какая разница какой путь — я вообще не пойму...
А по вашему "автолоадеры", что под капотом подключают файлы не иначе как через include/require конструкции, не столкнуться с проблемой такого рода? А что, вдруг, не так с "инклюдами" по путям? — или есть какой-то иной способ подтянуть файл, содержащий не класс? а с какой строчки начинается подключение того же composer в проекте?
Express скорее справедливо сравнивать с http микро-фреймвормами — у них есть микрокаркас приложения / http kernel, прослойка middleware, роутер, возможно какой-нибудь di-контейнер. Так что думаю, что корректнее будет его сравнивать с фремворками Slim, Silex, возможно Lumen, но никак ни Laravel/Symfony/ZF.
Странно, что так много комментирующих столь яро критикуют статью. Статья наглядно демонстрирует, что способов избежать использования синглтона более чем полно, особенно если заранее продумать всю архитектуру компонентов.
Хотелось бы сказать в защиту статьи, что синглтон считается антипаттерном не потому, что он ломает SOLID или ещё какие принципы, не дающие спать занудам-перфекционистам, а потому что даёт возможность обращаться к этому единичному инстансу из любой точки кода. Это и создаёт неприятные моменты, как минимум в коде начинающих программистов: вместо минимизации обращений к объекту через метод
MySingleton::getInstance()и передачиMySingleton $instanceв качестве параметра в востребованный конструктор/метод, его сразу вызывают напрямую из любого места в коде, ведь так можно — это вроде как статика, да и паттерн это позволяет делать, — отсюда и вытекают основные сложности с тестированием, с тем, что это трудно "замокать"/подменить.