там смысл в том, чтобы было быстро и просто

пимпл же, прототипы

я вот тут попробовал отделять веб от приложения

(это уже другая тема пошла)

и заюзать silex просто как модуль в приложении

со своим конфигом

не вижу смысла юзать silex)

почему?

удобный простой фронт-контроллер, удобный роутинг

MicroKernelTrait

симфони в один файл

тот же роутинг)

ну так оно одно и тоже по смыслу

крутой dependency injection который работает не медленнее пимпла и намного мощнее

любопытно

как ни старайся, всё равно в ларке он круче ?

как ни старайся, всё равно в ларке он круче ?

сча выйдет symfony 3.3 и тогда посмотрим)

только сегодня наткнулся на видос, там чел говорит, что не понимает, зачем микрокернел, если есть сайлекс ) https://www.youtube.com/watch?v=GG6K6T-5BdM

о нет

только не фреймосрач

только сегодня наткнулся на видос, там чел говорит, что не понимает, зачем микрокернел, если есть сайлекс ) https://www.youtube.com/watch?v=GG6K6T-5BdM

я полтора года работал с silex

мы не сремся

хотя потом можно будет цитатками отсюда аргументировать, почему тот или иной фрейм говно)

и знаешь чем заканчивался каждый проект который мы с ним начинали?)

я полтора года работал с silex

и я

> сча выйдет symfony 3.3 и тогда посмотрим) я хотеть контейнер, который не будет фризиться+

чем?

маленькой симфони

и где вообще нельзя добавлять строковые имена, которые не являются интерфейсами

ну то есть... все тоже самое но неудобно)

нууу в целом да

ну ок ок

> сча выйдет symfony 3.3 и тогда посмотрим) я хотеть контейнер, который не будет фризиться+

почему ты хочешь регистрировать сервисы в рантайме?

не только же сервисы там могут быть

уже говорили на эту тему =)

и где вообще нельзя добавлять строковые имена, которые не являются интерфейсами

тут есть нюансы. В 3.3 они как раз сделали все что бы делать имена сервисов интерфейсами и это было бы удобно. Но вот полностью отказаться от строковых имен нельзя в случаях когда тебе надо зарегать 10 сервисов с одним интерфейсом

можно же

контекстуальный биндиг+

уже говорили на эту тему =)

не, мне реально интересно. Я может забыл

контекстуальный биндиг+

эм... ивент листенеры например)

ну ок, вот есть у тебя репа, которая хранит конфиги юзера

в приложеньке

ну допустим

ну вроде нормальный кейс, да?

контекстуальный биндиг+

но вообще это крутая тема тоже)

а теперь репу переносим в БД

а, не, фигня

плохой пример, забудь

О!

))

class User implement Authentificatable {}

public function __construct(Authentificatable $user) { ... }

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

сервис А требует аутентикационную хреновину, а она появляется только после реквеста

это, кстати, более-менее реальный пример

сервис А требует аутентикационную хреновину, а она появляется только после реквеста

и тем самым ты закрываешь путь к неумирающему пыху

не закрываю

я такие штуки пихаю в сам реквест

и оно юзается исключительно как аргументы

и никакого желания запихнуть это добно в контейнер у меня нет

миддлвари, карл!

что мидлвари?

они ж stateless

состояние живёт ровно круг миддлварей

состояние живёт ровно круг миддлварей

я не понимаю желания зарегать такие штуки как сервис

ну вот вообще ни разу не понимаю

потому что это не сервисы

ERROR: S client not available

ну то есть... вот серьезно

есть у тебя какая-то штука которая появляется только после реквеста

почему ты где-то хочешь ее "инджектить"?

а не тупо передавать как аргумент?

я профита не вижу

(вполне возможно потому что мы по разному делаем дела))

а не пофигу как?

можно и аргументом

а не пофигу как?

с точки зрения модульности, связанности и т.д. не пофигу

нееееет

дааааа

ты думаешь что контейнер один на всё приложение

ты думаешь что контейнер один на всё приложение

нет, я могу делать контейнер на запрос например, PSR-11 позволяет)

ну т.е. исходишь из этого

воооот

теперь ты понимаешь к чему я клоню? =)

хочешь более реальный пример с которым я могу согласиться?

пул соединений с базой. У тебя есть общий базовый контейнер который хранит штуку выделяющую коннекшен. По запросу мы запрашиваем коннекшен из пула и выделяем его контейнеру который создаем на отдельный запрос

давай, жги+

не, фигня

почему?)

контейнер не нужен

нужен, просто он сверху

сам пул кидаешь в него, там Spl сторадж объектов

и по ключу возвращаешь что-нибудь

это детали реализации

суть в том что на каждый запрос (предположим что у меня демон и он обрабатывает одновременно несколько запросов)

я хочу задавать контекст что этому "инстансу" такой-то коннекшен, а этому другой

и делать это максимально прозрачно

проще всего это делать изолируя часть сервисов в отдельный контейнер который наслаивается над общим

короче, теперь я встал на сторону стейтлесс контейнера +)

короче, теперь я встал на сторону стейтлесс контейнера +)

эм... так контейнер и так стэйтлес)