MrPi

Так можно же реально интересный проект. Очередной фреймворк никому не нужен просто. Это не мое мнение - это реалии, которые легко проверяются на гите. 

Тогда полезное. Вот Sly32 хочет написать сервис для СЕО. Отличная задача. Попытаться систематизировать СЕО. Либо полезную веб утилиту, по типу защиты от ботов, или подобие клаудфлар (очень актуально).

Есть. Но челлендж это не увлечение, а соревнование. Если бы Вы сказали, что в свободное время кодите - никто и слова бы не сказал. Но здесь дух соревнования.

Так можно же написать полезную фичу. 

Репутацию заработать может. Заказчиков привлечь. Но лучшее портфолио - конечный продукт. Создай устойчивый, высоконагруженный, работающий сервис. Пусть узкой направленности. Обговори сроки и начни. После тест - DDOSим или тестируем UI, отлавливаем баги. Если всё ок - победитель. Забрал работы проигравших с передачей прав на домены, предоплаченный сервер на год. Есть награда, есть цель, есть реальное соревнование.

Я просто не понимаю смысла затеи. Есть микрофреймворки, которых десятки и даже сотни. Они просты. Остальное можно навесить. есть же репозитории с модулями. Через composer установить любые зависимости. Сейчас писать фреймворк, даже в челлендже - это странная затея. Пользы ноль. Есть комплексные решения - Лара, CI, Симфони, есть микро решения - slim тот же самый. Есть композитор и десятки тысяч репо, где прочитав issue или коммиты, в течении нескольких минут можно понять стоит внедрять или нет. А решений вагон. Лучше, соревнование в прод решении. Выбрали тематику, развили. Результат в конце срока - сравнили те же самые метрики - скорость, нагрузка, устойчивость к атакам. Вот здесь можно реально оценить уровень, а не в чистоте кода, который не имеет никакого отношения к работоспособности и никак не характеризует уровень программиста. Можно на чистом коде сделать ГС, а можно на говнокоде функциональный, быстрый. Да, не масштабируется, но задачу выполняет и безопасен. РАсширение, масштабирование - это про команды, а не единичных разработчиков. Те же популярные фреймворки ведут команды разработчиков

Так каждая команда работает по своему. У всех разные задачи. Кому-то CLI нужен, а на 80% сайтов - это мертвый код. Подход зависит от задачи. Реализация - от тимлида. Тим лид - человек, следовательно будет основываться на своем опыте, видении. Я же и пишу, что не понимаю критериев оценки. Есть много разных паттернов программирования. Что ближе, то и используют. Код может быть красивым, но терять на запросе или выполнении 2-3мс, что в итоге выльется в задержки, которые придется дебажить при увеличении нагрузки.

Магия, фасады, абстракция. Я выше писал, мой подход - DRY, KISS. Для меня лучшее решение - очевидное. Если любой дурак, увидев ошибку сможет её пофиксить - это идеальный код.

Вот Вы, к примеру строите фреймворк с подключением к разным БД. Вопрос: если по итогу будете использовать MySQL подобные (MariaDB например, через PDO) , зачем вам коннект с PostgreSQL? На будущее? А если оно не наступит? Мертвый код уже сейчас. Используете ORM? Для меня оптимален Query builder и нативный SQL в сложных запросах.

Так, а критерии оценки какие? Я чуть посматриваю на ваш челлендж, но не пойму, как оценивать будут. У всех разные подходы в программировании. Кто-то жертвует простотой статичных методов в угоду тестам, т.к. статику сложно мокать. Кто-то пишет спаггети код в угоду ООП, не следуя принципам DRY. Для меня ваш код избыточен и сложен по структуре. Не НЕ пониманию код, а по структуре самого фреймворка. Для меня антипаттерн - это Ларавель. Из всех крупных - мне ближе CI4. 

**
     * @inheritDoc
     */
    public function getParameterResolver(): ResolverInterface
    {
        if (isset($this->singletons[ResolverInterface::class])) {
            /** @var ResolverInterface $resolver */
            $resolver = $this->singletons[ResolverInterface::class];
            return $resolver;
        }
        $definition = $this->singletonsRegistry[ResolverInterface::class] ?? ResolverInterface::class;
        $this->singletons[ResolverInterface::class] = new $definition($this);
        return $this->singletons[ResolverInterface::class];
    }

$definition не проверяется?

Route::run() не соответствует принципам DRY. Слишком много повторений (и не только здесь). Конечно понятно, что это учебный материал, но, к примеру, я сторонник DRY, KISS, а другие только SOLID, кто-то чистый ООП в угоду простоте. По каким критериям оценка будет?

либо расстойку пропустили, либо некачественные жиры в слоях

Есть. Если учесть два вида тортов - одни с фабрики своей везут, другие по месту выпекают. В целом это полезная опция любого магазина. Есть излишки, продукт подходит к концу срока - в печь его. Издержки уменьшаются и на просроке делается х3-х4

Ох уж эта женская логика. Нет, бываю в Спаре. Нравятся торты именно которые в магазине пекут, например наполеон или медовик. Последнее время не беру, после новости об отравлениях.

Апну тему. Что сделали с авторизацией через сторонние сервисы? Пользователь сейчас ленив и почта + 2 пароля + несколько галочек согласия с куками, правилами отпугивает их. Через сторонние учетки удобно. И каких сайтов коснется закон? Как определить принадлежность сайта? Если он не нацелен на аудиторию одной страны?