Разработка микрофреймворка

[claygod]

Здравствуйте!

Разрабатываю маленький фреймворк для собственных нужд. Хочется, чтобы код посмотрели и потыкали носом в очевидные косяки опытные программеры.

Интересуют ошибки, которые возможно (и наверняка) есть в ядре фреймворка, поскольку надстроечные презентеры в нём сделаны прежде всего для собственно поиска очевидных ошибок.

Архив фреймворка - http://rumba.net.ru/download/rmfw/rmfw_036.zip
как он устроен в общих чертах - http://rumba.net.ru/new-micro-framework-php-rumba.html
сгенерированная документация - http://rumba.net.ru/download/rmfw/rmfw_036_docs.zip

 

[Фанат]

Стандартное замечание - код выложи на гитхаб.
Это совсем нетрудно, но без этого никто смотреть не будет.

 

[hell0w0rd]

а после публикации на гитхабе и packagist.org, сразу сравнение с Silex/Slim. Пока я вижу тучу синглтонов, а такого в ядре точно быть не должно.

 

[Вурдалак]

Нет, на packagist нужно регать только что-то адекватное.

 

[hell0w0rd]

Ну Yii же на packagist есть

 

[keltanas]

Ну Yii же на packagist есть

Да ладно тебе )) В те времена, когда появился Yii, он вполне занимал нишу, на которой сейчас ютится Laravel.

 

[claygod]

Стандартное замечание - код выложи на гитхаб.

Сейчас тексты комментов в файлах на руском языке, как переведу, выложу.

Пока я вижу тучу синглтонов, а такого в ядре точно быть не должно.

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

 

[Фанат]

Сейчас тексты комментов в файлах на руском языке, как переведу, выложу.

Нет проблем и с русским, лишь бы в utf
снобы будут плеваться, но на них можно не обращать внимания

 

[AnrDaemon]

Я считаю, что ядро, это как-раз те классы, у которых может быть только один экземпляр

А если мне приспичит стыковать два проекта с разными настройками, написанных с применением твоего фреймворка?… Синглетоны оправданы только там, где без них НЕВОЗМОЖНО обойтись.

 

[С.]

Да ладно докапываться. В конце концов это МИНИ-фреймворк. Специализацию и минимализм еще никто не отменял. Кроме того, надо быть абсолютно ленивым ублюдком, чтобы смерджить два проекта на одном фреймворке и не превести их к одному ядру.

 

[fixxxer]

Сейчас тексты комментов в файлах на руском языке, как переведу, выложу.


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

Единственность инстанса должна обеспечиваться с помощью механизма управления зависимостями фреймворка.

Один экземпляр - какого класса? Твоего, или моего, который я отнаследовал от твоего, дописав мне нужное?

 

[claygod]

От наследования можно защититься через объявление класса финальным (ИМХО, сам ни разу не финализировал класс). Остальные экземпляры (не синглтоны), создаются через фабрику, хотя конечно, можно и эти четыре (синглтона) создать через фабрику с особыми условиями (фабрика будет "знать", что эти классы - особые и не позволит сделать лишний экземпляр). При таком раскладе это конечно уже будут не синглтоны.

 

[hell0w0rd]

claygod, https://github.com/silexphp/Silex - посмотри на фреймворк. В основе лежит мааленький, но крутой DI-контейнер, который отвечает за то, чтобы экземпляр объекта был всегда один, все расширяется. Может быть тебе стоит просто сделать сборочку "под себя"?

 

[claygod]

hell0w0rd, а в нём не Pimple ?
https://github.com/fabpot/Pimple

 

[fixxxer]

Он. Я нечто похожее, не зная про pimple, в свое время тоже писал. =)

Alternatively, Pimple is also available as a PHP C extension

Занятно.

 

[claygod]

fixxxer, посмотрел твой класс по ссылке, вот вопрос, который мне не сильно понятен: к примеру у нас есть класс, который регистрирует резолвы, соответственно, КОГДА уместно, или наоборот, когда неуместно это делать. Кроме того, все ли классы ты инициируешь через этот сервис, или только ядро? Опять таки, насколько логично там же иметь возможность и регистрировать переменные, ведь совершенно спокойно возможен конфликт имён классов и переменных.

 

[fixxxer]

claygod, там у меня 1 в 1 как в Pimple, только get/set/call-magic вместо ArrayAccess, соответственно, и использовать так же. Сервисы просто именуются, к реальным названиям классов никакого отношения нет.

Уместно ровно в тех же случаях, в которых уместны сервис-провайдеры в Laravel, DI в Symfony итд.

 

[claygod]

А вы не пробовали делать через статический класс зависимости?
С одной стороны, менее гибко, с другой - легко реализуемо. $Container::get/set($attr);

 

[fixxxer]

Это получится service locator, а не DI. Это плохо: зависимости надо инжектить в конструктор, а не бесконтрольно дергать откуда угодно.

 

[Redjik]

Pimple только отложенную инициализацию не умеет =(
Уже размышляли об этом в другой ветке.
Типо когда контроллер как сервис, и мы внедряем обьект mailer, который может вообще не понадобиться, если рега не прошла.
Но это решаемо.

upd.
нашел - http://symfony.com/doc/current/components/dependency_injection/lazy_services.html