1) у вас два репозитория. Локальный и удаленный.
2) pull забирает изменения из удаленного репозитория и синхронизирует их с локальным
3) если в удаленном репозитории ничего нет - вы ничего не сделали.
4) push точно так же отправляет изменения из локального в удаленный реп
5) читаем книжку pro git: https://git-scm.com/book/en/v2
MrDickson: чикипуки это если в одном файле. А так пых ничего САМ не видит и не подключает.
Пространства имен имеют отношение только к именам классов (гуглить FQCN) и ниначто больше не влияют. Это эдакий кастыль (как и в других языках вроде java) в виду отсутствия настоящих модулей. Мол все имена классов в PHP находятся в глобальной области видимости и что бы не делать длинные и уродливые имена (как в былые времена) и не беспокоиться о коллизиях в именах и испльзуют эти штуки.
А классы нам как нужно было ручками подключать (автозагрузка это тоже ручками но проще) так и нужно.
Михаил: dependency injection - это для того что бы рулить зависимостями и не писать руками фабрики.
Декораторы - это декораторы. Вы пишите их только тогда когда они нужны. Они нужны что бы "добавлять" повезение объектам не меняя их и не нарушая принцип единой ответственности. Это позволяет уменьшить количество причин по которым вам захочется поменять ваш код. (маленькие вещи менять проще, а еще с маленькими штуками старые можно выкинуть и написать новые, и это будет быстрее чем править жирную хрень)
1) это синхронная логика так как вы сами решаете когда этот лог ивентов отправлять на дальнейшую обработку.
2) вы не создаете ивент "пошли письмо", это даже звучит слишком глупо и императивно. Вы создаете ивент "новая посылка" и далее уже обрабатываете как хотите. Можно хоть привязать действие на матчинг определенной последовательности действий.
Если коротко - в domain events объект пораждающий события лишь их запоминает. То есть когда мы вызываем код "$this->rememberThat(new UserRegisteredEvent($this))" мы не инициируем никаких ивентов, у нас не запускается асинхронная логика и т.д.
Когда мы закончили работать с объектом мы просто забираем массив всего что с ним происходило (что очень легко дебашить потом), и уж там как нам удобно. Можем ифами разруливать там где забрали, можем по fos flush-у доктрины забирать и закидывать в event dispatcher... как угодно.
В данном случае мне видится разумным сделать так
Что за ужаный getService в неймспейсе Domain? А как же dependency injection?
Роман: ну мол лучше заменять их на ивенты которые ближе к предметной области. DomainEvents очень хорошо с этим помогают и помогают выстроить более четкий флоу обработки оных, ну и тестировать просто поскольку нет ивент эмитеров всяких.
Михаил: у вас не должно возникать желания "вызывать метод с кешированием или без", это решение по идее должен принимать сам декоратор на основании какой-то логики инвалидации кэша.
copal: вот только с таким объяснением у людей нет понимания зачем вообще объекты нужны если были структуры.
Объект - это некая штука которая что-то делает. И вся суть сделать так что бы нам было пофигу КАК оно это делает. А когда мы рассматриваем объект изнутри, и он не наш (то есть мы сейчас вообще другой объект рассматриваем а это просто зависимость), то что-то явно пошло не так в плане инкапсуляции.
Типичный пример - геттеры и сеттеры у объектов. Вроде бы все клево, напрямую данные наружу не ходят. Но допустим у нас был объект "деньги" и мы хранили там денежку в float (для js это не проблема конечно, я больше для примера), а потом до нас дошло что так лучше не делать и мы хотим переделать float в int, но наш геттер все еще возвращает float. И мы не можем это поменять потому что наш геттер использует код, который мы не контролируем.
Альтернатива - для любых операций которые нужны приложению предоставить метод, не предоставляющий информации о внутреннем устройстве и как объект хранит данные. То есть вместо
if (a.price > b.price) {
можно написать
if (a.hasLowerPriceThan(b)) {
это и читается лучше, и контролю большему поддается. Есть куча нюансов конечно которые нужно учитывать... но основной посыл - инкапсуляция и изоляция возможных изменений.
Nikita Schipilov: да нет, не трудно. Вам нужно разобраться с прототипным наследованием, что куда копируется при инстанцировании объектов и т.д. По ссылке что я привел все это есть.
Владислав: если у вас есть инфа от symfony profiler значит у вас только не production окружение.
p.s. в любой непонятной ситуации с производительностью юзайте blackfire. Помниться когда-то давно у меня на винде симфони долго запускалась так как узким местом была файловая система (ntfs).
Михаил: воу..... я два дня назад размышлял "взять ли магенту за основу для проекта или нет".... спасибо что показали - мой ответ - нет, так не должно быть.
Из того что я вижу - где-то 2/3 зависимостей там не нужны и их "запихнули" что бы покрыть нужды 10% возможных кейсов. Универсальность и все такое. В сущностях подобное - плохо.
Только вот там тысячи файлов и в __construct по 50 строк бывает.
ну то что по 50 строк в конструкторе - если там 50 зависимостей (или больше 10-ти) то мы имеем дело с очень связанной сущностью которая требует дофига и скорее всего нарушает принцип единой ответственности. А то что "файлов тысячи" - это нормально для проектов такого масштаба. Система становится гибкой когда достигается баланс связанности. Маленькие объекты проще заменять, и система становится в целом гибче.
google translate в помощь. Вообще чтение документации позволит вам еще и английский чуть поднять, так что может стоит этим заняться?