у тебя symfony/di ?

да

могу адаптер набрасать для него под свою либу

и тебе ничего в проекте менять даже не придется

оверхед будет минимальным

как же не придется, а автовайринг, частичные аргументы, nonshared сервисы и тд?

все должно работать будет из коробки)

так оно будет просто юзать контейнер симфони

ога, захочешь отказаться будешь выносить от туда

в то что понравилось

не ты не понял, так ничего не покажет ведь

но я согласен пока у меня одна потенциальная проблема отсутствие кэша в тех местах где работаю с reflection

но не должно быть просадок по производительности

если б все так просто было, симфони не компилировало бы контейнер

ну хз

я делал и больше контейнеров

и обычно все они не нужны сразу

в сифмони кстати тоже lazy по-умолчанию, он тебе не будет сразу инициализировать все что только возможно если это не требуется

ну да это фитча которая появлятся стала после 2015 года

я хочу вынести свой контейнер в shared memory через подобную штуку https://packagist.org/packages/gpslab/shmop

но надо бенчмарки и это разные research

которые по итогу повысят мои скилы)

зачем shmop? файлы и opcache

шустрее должны быть чем сериализация

надо мерить на практике

но да согласен opcache хорошо

ну да это фитча которая появлятся стала после 2015 года

ты выше скидывал линк на доку свою, типа у тебя все по-умолчанию лейзи, а в симфе нет

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

ты выше скидывал линк на доку свою, типа у тебя все по-умолчанию лейзи, а в симфе нет

неа я такого не говорил, я говорил что в pimple сталкивался с таким

то что я стараюсь все делать lazy да

следующим https://github.com/smpl/mydi/blob/master/doc/dynamicConfiguration.md в php-di и symfony/di есть но не всегда

вот же

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

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

как массив

и получают оверхед, а я к тому что lazy это обязательная штука которая должна быть в любом di

посоветуйте crash course по uml

у этой либы только один плюс - при приеме на работу)

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

но основное что я делал это даже не скорость (хотя это важно) а гибкость и удобство

для пользователя (программиста использующего либу)

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

а автовайринг?

он есть

а автовайринг?

https://github.com/smpl/mydi/blob/master/doc/provider/reflectionService.md

вместо @autowiring использую @inject но имя анотации можно менять

или ты про @autowire как в spring ?)

вместо @autowiring использую @inject но имя анотации можно менять

это рак

или ты про @autowire как в spring ?)

это тоже рак

ну то есть как, если бы аннотации в пыхе были как аннотации в java...

это вы о чем?

а почему в пых не хотят добавить аннотаций?

чего это autowire рак, это же одна из основных фич DI

Сергей наверное аннотацию имел ввиду

да, аннотацию

когда это тебя аннотации покусали?

не все аннотации. Конкретно эти - в них не вижу смысла

сторонник конфигов?

почему?

типа что их фигово в деве перекомпиливать, надо отдельный вотчер держать?

а, я бы даже обобщил, аннотации для di или orm бессмысленны

))))

хз, по мне так аннотации норм, если вы из-за этого не уперлись в скорость чего бы то ни было

так сказать наименьшее зло

а, я бы даже обобщил, аннотации для di или orm бессмысленны

А для ОРМ почему?

для ORM норм

ERROR: S client not available

а как у тебя орм сущности от модели отделяются?

никак?

сущности часть доменной модели

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

не понял про абстрактные классы модели

зачем от них сущности наследовать?

конфиг орм отдельно, в нем немного дублируется инфа из сущности, это да, ну или в аннотациях около пропертей прямо в классе. Больше там инфы от ормки особо и нет

делаешь класc abstract class user { тут модель } и class userentity extends user { тут специфичное для орм }

а что такого специфичного для orm в entity?

то, что тебе не нужно в доменной модели

а орм без этого не работает

например?

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

ну сеттеры не нужны

ненужные связи тем более))

вот что-то там было в доктрине из-за чего нужен геттер для связи

всё же не ясно, чем отличается модель от orm в этом случае ))) как я понял в сущности ты пихаешь только проперти с маппингом. а в модели всякие calculateSmth и т.д. и т.п.... но тогда не ясно почему это не может быть в сущности

если брать доктрину, будет много аннотаций размазано на несколько экранов (yml конфиг же пару десятков строк). 90% аннотаций кстати можно было бы разрулить используя @ var + конвенции, а 10% уже тогда всё равно куда пихать было бы

все же проще контролировать аннотации, чем отдельный маппинг

как говорит core разработчик doctrine - не используйте yml

ни

ко

гда

аннотации - всё что вам нужно

аннотации для своих проектов, xml для опенсорса

если хотите пошарить бандл - юзай xml

аннотации для своих проектов, xml для опенсорса

+

а он говорит какая боль внутри этих аннотаций?

какая

я хз как yml может быть удобнее чем аннотации

^ Тож самое

ну доктрина да, заставит аннотации писать