Это статья не про очереди, а про работу с доктриной в целом, в примере у меня про задачи (Task), но на деле это может быть что угодно. Вы сейчас говорите, что эту задачу в частном случае можно было решить «вот так», а я говорю вам про общий случай.
В Doctrine ODM не транзакций.
В Doctrine ORM есть, но судя по документации «в случае пожара» нужно закрыть EntityManager, правда что с этим дальше делать не ясно. Я с ORM не работал, может кто подскажет тут. Может даже Вы?
Это все спорно и скорее всего это тема для отдельного холивара. Не плохо было бы если Вы сослались на авторитетный источник. К примеру автора подобного заявления заминусовали на здесь на хабре habr.com/ru/post/476142
Так или иначе даже в случае исключения бывает необходимо записать информацию в базу данных. Например, если в ходе обработки видео-файла мы поняли, что он поврежден.
В статье преведены примеры проблемы в том числе и с try..catch, который к самой проблеме имеет весьма посредственное отношение. Суть в том, что менеджер документов это своеобразный реестр. Об этом тоже в статье есть :)
Увидел про декораторы и обрадовался, подумалось про аннотации говорится (в тайпскрипте они декораторами называются). Но нет, какая-то очередная магия, честно даже понять не смог, что там происходит.
Ну попробуйте в метод с тайпхинтом int передать что-то другое, получите рантайм исключение. Вот в typescript рантайма нет, а дженерики есть. И я знаю про статические анализаторы типа plasm и phpstan, что-то у них тоже есть дженерики, вас это не сиущает? Смысл тогда в php вообще внедрять тайпхинты, чтобы потом их в двух местах дублировать?
Статическая типизация без дженериков это какой-то мазохизм. Ты вроде можешь тайпхинтить, но как только дело касается массивов — здравствуй phpdoc. В итоге тип прописан и в самом методе и в документации к нему. И коллекций нормальных не появится, покуда нет дженериков. Зато для массивов хотят магии добавить — просто рука-лицо.
Дженерики через @ сделают
В Doctrine ORM есть, но судя по документации «в случае пожара» нужно закрыть EntityManager, правда что с этим дальше делать не ясно. Я с ORM не работал, может кто подскажет тут. Может даже Вы?
В статье преведены примеры проблемы в том числе и с try..catch, который к самой проблеме имеет весьма посредственное отношение. Суть в том, что менеджер документов это своеобразный реестр. Об этом тоже в статье есть :)
Но я не говорю, что их надо оставить в phpdoc'e, нет.
Не понятно чем не понравились аннотации как в java (те, что сейчас в phpdoc)… Обязательно что то новое придумывать?
Увидел про декораторы и обрадовался, подумалось про аннотации говорится (в тайпскрипте они декораторами называются). Но нет, какая-то очередная магия, честно даже понять не смог, что там происходит.
Будем дальше в симфони страдать с phpdoc.
Ну попробуйте в метод с тайпхинтом int передать что-то другое, получите рантайм исключение. Вот в typescript рантайма нет, а дженерики есть. И я знаю про статические анализаторы типа plasm и phpstan, что-то у них тоже есть дженерики, вас это не сиущает? Смысл тогда в php вообще внедрять тайпхинты, чтобы потом их в двух местах дублировать?
Статическая типизация без дженериков это какой-то мазохизм. Ты вроде можешь тайпхинтить, но как только дело касается массивов — здравствуй phpdoc. В итоге тип прописан и в самом методе и в документации к нему. И коллекций нормальных не появится, покуда нет дженериков. Зато для массивов хотят магии добавить — просто рука-лицо.
Какая вселенная, алло… Тайпхинты это про статическую типизацию (антоним динамической), а не про строгую (сильную) / слабую
Пока все живут в 2019, автор уже пребывает в 2020.
Нужно получить эти числа не путем ввода, а путем разнорообразных математических операций.
Первое что бросилось в глаза, это метод next() который возвращает генератор. Дальше даже смотреть не стал.
Мне почему-то при чтении статьи показалось, что сначала оперировали int, а потом добавили отдельные типы данных.