Выложен в публичный доступ репозитарий Альто 2.0

Я не слепой, видел, я указал на возможный исход.

Имхо такое сращивание просто..ненадо...

Сначала отвечу про php7 — у меня сейчас несколько проектов работает на текущей версии Альто в конфигурации nginx+php7. Для новой версии минимум php 5.6 значится не потому, что под семеркой не будет работать, а просто потому, что фичи семерки в ней не используются. Но сам код отлично крутится под php7.

У меня имеется проект на альто под php 7.1 и работает он весьма плачевно, пришлось достаточно сильно изменить конфигурацию, а так же решить вопрос с полифилом под mbstring библиотеку. Главная страница админки с тестированием под php 7.1 даже не отображается, работает только левое меню и остальные функции.



Синглтон по своей парадигме уже является антипаттерном ввиду того, что статическое обращение к объекту весьма дорогая операция в идиологии php.
Обращение к фасадам через контейнер удешевляет данную операцию, т.к. интерпретатору не нужно постоянно объявлять объект глобально, он использует уже инициализированный объект в рамках вышеназванного контейнера.

Так что если вдруг сложилось впечатление, что я не знаю современных движков — это не так. ))) Знаю, пробую на практике, смотрю, что хорошего можно из них взять в Альто.

Ни в коем случае, темболее что, симфония и слим это не движки)

Сейчас в Альто 4 класса паттерна Singleton — Application, Router, Engine, Storage (с наследником Config).

Насчет синглтона понятия давно размытые, но я привык считать его антипаттерном из-за того, что еще со времен пхп 4, когда этот паттерн стал чертовский модным, многие люди не правильно поняли парадигму SOLID, а конкретно «Single Responsibility Principle». Паттерн синглтона очень скверный и сложный в реализации правильно, он усложняет юнит тестирование, лишает смысла «принцип единой ответсвенности» ввиду того, что он обязан следить за самим объектом синглтона, а так же за тем за чем он реализован — это и принцип единой ответсвенности разные вещи.
Проблема паттерна продолжается в том, что при обычных его реализациях обратится к «переиспользованию» объекта не реально. Именно потому нам на помощь приходят фасады и контейнер — фасад это структурный паттерн, он позволяет скрыть сложность системы путём сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам. А контейнер позволяет отслеживать состояние объекта, в том числе проверять единственный экземпляр был инициализирован или нет, а темболее не мешает переиспользовать объект еще раз создавая его новые экземпляры под конкретные нужды.

Я не говорю про проблему синглтона с работой зависимостей с ним достаточно сложно работать, так же достаточно сложно следить за ним состояние объекта при необходимости работы одного объекта в нескольких потоках. К примеру JVM не позволяет проверить существует ли один экземпляр объекта в пространстве, он всего-лишь проверяет существует ли экземпляр объекта в текущем загрузчике, однако сложные проекты на java пишутся с использованием более одного загрузчика. (это для примера минуса синглтона)

В репозитории я заметил именно синглтон объекты Application, Engine, PluginManager, Router, Storage, HookManager — тестирование этих объектов очень усложнено, изолировать их методы между собой весьма сложно.

На мой взгляд на текущий момент лучше пойти с использованием паттерна DI, в том числе внедряя сервис-провайдеры, которые позволят построить как структурное приложение (Приложение —> События —> Роутер —> Модули —> Ответ), так и внедрить модульную систему, где каждый модуль сможет иметь свой сервис провайдер, а так же сможет влиять на всю систему целиком сразу после установки модуля, без необходимости писать инструкции по изменению кода (пример системы octobercms, система после установки плагина в том числе расширяет модели других объектов/системы, при этом не влияя на основную логику расширяемой модели)