Из-за модели работы PHP — рождаться и умирать, всегда будут проблемы с производительностью. Поэтому PHP сейчас подходит для средних и небольших проектов, для крупных нестандартных проектов есть более подходящие языки и архитектуры, моё субъективное мнение.
Частично ответы на ваши вопросы в статье, частично в комментариях.
Стиль именования классов и неймспейсов как в Java, пакеты все с маленькой буквы, классы с большой.
P.S. OpenSource для того и нужен, чтобы найти единомышленников еще до релиза и развивать проект. Многие известные Open-Source проекты до сих пор не имеют стабильных версий (т.е. нулевые версии.)
Да все классы связанные с ActiveRecord устарели и не используются, их надо будет удалить. Они остались еще со времен, когда не планировалось внедрять стороннее решение по типу Propel.
Сканер полезен тем, что хранит мета-информацию о файлах, с помощью которой можно сделать удобную авто-регистрацию классов. Например, в проекте вы объявляете новый класс Тега для шаблонизатора. То что вы наследуете его от абстрактного класса тега, уже дает знать фреймворку, что вы хотите его использовать. Не нужно думать о том, где прописывать регистрацию этих тегов. Это один из примеров.
Я никого не призываю переходить на этот фреймворк. Скорее сейчас я больше заинтересован в людях, кому будет интересно вложить свой вклад в проект в качестве разработчиков фреймворка.
Это нормально. Некоторые фреймворки специально задумывались для этого (Symfony).
Но есть фреймворки, архитектура которых иная. Play framework для Java и Scala как пример. В начале статьи я писал, что ориентировался на этот фреймворк.
ActiveRecord это вы имеете ввиду Propel ORM? Я думаю при желании логику работы с моделями можно выносить в отдельные классы-сервисы и подключать их через DI в контроллеры.
Конечно я осознавал, что делая что-то сложное, я теряю в производительности. Но я еще исходил из того, что если мне нужно писать что-то крупное и нагрузочное у меня для этого есть Java, а php можно использовать только как Frontend. Например для этих целей очень удобно использовать Apache Thrift.
На счет скобочек, проект в разработке и думать о скобочках нет времени. Форматирование исправляется подходящими инструментами за несколько минут. Говоря про стандарты, я меньше всего имел ввиду такие мелочи в code-style.
В исходниках фреймворка есть методы по типу: put, putAll и в этом духе, поэтому не хотелось менять порядок, т.к. суфикс all используется во многих местах.
Я не изучал досконально Laravel, поэтому ответить на вопрос не могу.
Приделать можно, но используя фреймворк вам делать этого не нужно, вам много чего приделывать в этом фреймворке не нужно. Когда есть большое количество решений одной проблемы, каждый приделывает что-то свое. Таким образом размывается единый стандарт пользования фреймворка. И получается, что каждый использует один и тот же фреймворк, но с разными инструментами.
Всегда будут противники коробочного решения. PHP-Parser (проект для парсинга php-кода) делает примерно тоже самое что и PHP_CodeSniffer. EAP работает не весь год.
Не у всех есть лицензия на PhpStorm и не все ею пользуются. К тому же в IDE это все на уровне необязательных к исполнению подсказок. А так можно организовать проверку на стороне сервера интеграции, а это снижает риск возникновения ошибок и попадания в репозитарий «плохого» кода. Проверка во время открытия страницы сделана как полезное дополнение, для удобства разработчика.
Regenix позволяет интегрировать любые другие шаблонные движки. Скрипт build и так возможно запускать из CI. С таким же успехом можно заменить в любом другом фреймворке все на компоненты Symfony2.
Используется php файловый кеш. Но вообще фреймворк не ориентирован на среду без кеша. Я пришел к выводу, если нет кеш системы (которая хранит данные в RAM), невозможно поддержать быстродействие в PHP на должном уровне. Кеш используется буквально по-всюду.
Стиль именования классов и неймспейсов как в Java, пакеты все с маленькой буквы, классы с большой.
P.S. OpenSource для того и нужен, чтобы найти единомышленников еще до релиза и развивать проект. Многие известные Open-Source проекты до сих пор не имеют стабильных версий (т.е. нулевые версии.)
Сканер полезен тем, что хранит мета-информацию о файлах, с помощью которой можно сделать удобную авто-регистрацию классов. Например, в проекте вы объявляете новый класс Тега для шаблонизатора. То что вы наследуете его от абстрактного класса тега, уже дает знать фреймворку, что вы хотите его использовать. Не нужно думать о том, где прописывать регистрацию этих тегов. Это один из примеров.
Но есть фреймворки, архитектура которых иная. Play framework для Java и Scala как пример. В начале статьи я писал, что ориентировался на этот фреймворк.
Конечно я осознавал, что делая что-то сложное, я теряю в производительности. Но я еще исходил из того, что если мне нужно писать что-то крупное и нагрузочное у меня для этого есть Java, а php можно использовать только как Frontend. Например для этих целей очень удобно использовать Apache Thrift.
На счет скобочек, проект в разработке и думать о скобочках нет времени. Форматирование исправляется подходящими инструментами за несколько минут. Говоря про стандарты, я меньше всего имел ввиду такие мелочи в code-style.
put, putAllи в этом духе, поэтому не хотелось менять порядок, т.к. суфикс all используется во многих местах.Приделать можно, но используя фреймворк вам делать этого не нужно, вам много чего приделывать в этом фреймворке не нужно. Когда есть большое количество решений одной проблемы, каждый приделывает что-то свое. Таким образом размывается единый стандарт пользования фреймворка. И получается, что каждый использует один и тот же фреймворк, но с разными инструментами.