я пытался навести его на мысль о событийной модели интеграции, но натолкнулся на контраргументы: такая модель потребует избыточной инфраструктуры для поддержания кэша, неизбежно породит проблемы с консистентностью данных
Проблема "серых" исправлений и консистентности данных Инцидент с "лавиной событий" Осознавая недостатки всех предыдущих вариантов, мы разработали гибридный подход, который лег в основу нашей интеграции:
Ну то есть он был прав?
А как быть с доступностью? Если АБС "легло" на плановое обслуживание или из-за инцидента, как мы будем предоставлять сервис клиентам?
Как быть с доступностью, если ДБО "легло" на плановое обслуживание или из-за инцидента?
В тот, в который звуковой рецептор дает импульс. Это сводится к вопросу о количестве молекул в разных взаимодействиях, то есть к дискретным частям.
если в лесу, где никого нет, упало дерево, будет ли шум?
Будет. Это аналогично вопросу "Если в галактике, где никого нет, взорвалась звезда, будет ли свет?". По наблюдениям мы знаем, что он будет, и будет идти по Вселенной миллионы лет.
так как всегда существуют другие вещи между существующими вещами, и снова другие между ними и так далее до бесконечности
Это утверждение не доказано.
но к существующим вещам всегда можно добавить новые, что противоречит конечности. Вывод: бытие не может быть множественным
Нет, вывод должен быть, что к существующим вещам не всегда можно добавить новые.
Но чтобы вещи отличались, между ними должно быть нечто иное Однако если между вещами есть что-то, то это "что-то" тоже должно быть вещью, и тогда оно тоже требует разделения
Нет, внутри самой вещи разделение не требуется. Даже "между ними должно быть нечто иное" не требуется, достаточно, чтобы другая вещь была чем-то иным, чем первая. Но это поднимает вопрос границы, где именно заканчивается одна вещь и начинается другая.
Вывод: невозможно логически обосновать существование конечных, отдельных друг от друга вещей.
Нет, вывод в том, что каждая часть вещи не может делиться до бесконечности.
значит эти дискреты пространства, раз они реально существуют, тоже должны находиться где-то, в чем-то, в каком-то другом пространстве
Необязательно. Можно предположить, что Вселенная это и есть такое пространство. Можно предположить, что они просто есть как первичная сущность, которой не нужно своё пространство. Можно предположить, что просто вещи двигаются в пространстве на дискреты, а сами дискреты как физическая сущность не существуют.
Не может быть много одинаковых "одних", так как раз они одинаковы, то они не множественны
Это неправильный вывод. Даже если у них одинаковые собственные характеристики, они могут различаться положением в пространстве, так что их может быть много.
Выглядит так, что все апории Зенона разрешаются введением квантов. Ахиллес догонит черепаху только потому, что проходит 1 квант пространства за меньшее количество квантов времени.
Логически, чтобы что то отличалось от чего то другого, такое отличие и есть элемент сознания.
Нет, логически есть реальные предметы со своими различиями и есть их наблюдение, и это не одно и то же. Так же как исходный предмет и его фотография. Фотоаппарат может не делать фотографию предмета, но предмет от этого не исчезает.
Воспринимайте базовые элементы сознания как признаки различения чего-то на фоне всего остального
Вы путаете сознание и интеллект. Они связаны, но это не одно и то же. Если любое различение приписывать сознанию, то не останется ничего, что можно приписать функциональности интеллекта.
но его мешает проходить этерналистическая установка
Ну вам может и мешает, не надо говорить за других.
Если есть отличительные признаки, есть и информационные структуры.
Нет, вполне может быть так, что эти отличительные признаки в данный момент никто не наблюдает. Но они могут оставить следы, которые потом будет наблюдать кто-то другой.
Это неверное утверждение. Мир устроен, просто может быть так, что никто не воспринимает его устройство. Взрывы сверхновых произошли миллионы лет назад, когда еще не было осмысливающих наблюдателей, а воспринимаем мы их только сейчас. Значит миллионы лет назад мир уже был устроен в виде звезд.
Я вам уже доказал со ссылкой на документацию, что это утверждение ложно. Меньший расход памяти в определенных операциях является основной причиной их добавления.
И? Там есть предложение написать этот код. Мое высказывание это возражение на это утверждение, а не ответ на какой-то вопрос. Не все высказывания являются ответами на вопросы.
И поэтому ваш ответ, "генератор это и есть место, чтобы поместить туда этот код" не имеет смысла.
Имеет. Если вы его не поняли, это не значит, что его нет. Это указание на то, что предложение "Извлекаете порциями и сохраняйте после извлечения" и так всем понятно, и это оно не имеет смысла.
зачем сначала читать ВЕСЬ миллион записей, и только потом начинать записывать в БД?
Затем, чтобы не менять вызывающий код, в котором уже написан foreach. Или не усложнять, если еще не написан.
Не дали его и вы.
Дал, просто вы невнимательно читаете. А в этой ветке этот ответ не нужен.
Это основной, базовый алгоритм.
Нет, это уже оптимизация базового алгоритма.
Разница только в "вызывающем коде", который ни к алгоритму, ни вопросу в исходном комментарии отношения не имеет.
Он имеет отношение к генераторам. В контексте которых написан исходный комментарий.
И здесь опять вы опять вырвали предложение из контекста.
Не вырвал из контекста, а показал, что это глупый вопрос. Если бы он был задан как-то по-другому, то возможно он не выглядел бы глупо. Из файла нужно извлечь миллион записей и все их сохранить в БД, нет смысла спрашивать зачем.
То есть вопрос не "зачем извлекать и записывать", а "почему не извлекать порциями?"
Ну вот так и надо было спрашивать.
То есть читать весь миллион - хоть с генератором, хоть без - нет никакого смысла.
Есть, если памяти достаточно, проще сделать функцию, которая извлекает из файла сразу все данные, и не возиться с генератором.
Я вас уже спрашивал, в чем вы видите разницу, вы не ответили. Видимо ответа у вас нет. Естественно, при использовании foreach, большие объемы данных обычно обрабатывают через foreach. Он подразумевается по контексту. И нет, генераторы можно использовать и в других циклах.
Вы здесь из пальца высосали некий метод $db->query(), который исходно возвращает массив.
Ну так это и есть основной сценарий использования генераторов.
Вместо массива, метод query() должен возвращать переменную
Нет не должен, мне нафиг не надо раскидывать эти детали реализации в вызывающем коде по всему приложению. Я сделал функцию query именно затем, чтобы их туда спрятать.
И здесь легко увидеть, что исходный цикл стал основой генератора.
Это не легко увидеть, потому исходный цикл остался в вызывающем коде, который вызывает вашу getOrders(). Вы опять использовали логическую манипуляцию и привели пример кода не полностью. Если бы исходный цикл стал основой генератора, то он бы не остался в вызывающем коде.
И даже вы, если сможете немного умерить свою спесь
Спесь проявляете тут вы. Оскорбляете других и применяете логические манипуляции, чтобы иметь хотя бы какое-то обоснование высокомерного поведения. Игнорируете прямое объяснение из документации от разработчиков языка, зачем нужны генераторы. Там прямым текстом написано, что назначение генераторов - уменьшить расход памяти в приложении. На этом можно закончить.
Генератор же - это такой конвертор, который позволяет результат любого цикла представить в виде массива.
Это полностью неверное утверждение. Это не является ни назначением генератора, ни описанием его работы.
Чтобы результат любого цикла представить в виде массива, можно просто складывать в массив, генератор для этого не нужен. Поэтому делали его для другого.
А в виде массива (одномерного) он представляет не "результаты цикла", а значения после оператора yield. Которые могут быть в одном цикле, в нескольких вложенных циклах, или вообще без циклов.
Если исходный цикл не экономит память, то и генератор на его основе ничего не сэкономит.
Да ни при чем тут исходный цикл. Для экономии памяти генератор не оборачивает исходный цикл, а добавляет новый.
Исходный цикл:
$orders = getOrders();
foreach ($orders as $order) {
processOrder($order);
}
function getOrders() {
return $db->query('SELECT * FROM products');
}
Цикл с генератором:
$orders = getOrders();
foreach ($orders as $order) {
processOrder($order);
}
function getOrders() {
$offset = 0;
$limit = 100;
do {
$res = $db->query('SELECT * FROM products LIMIT $offset, $limit');
foreach ($res as $row) {
yield $row;
}
$offset += $limit;
} while(count($res) > 0);
}
Исходный цикл как был так и остался, а не стал основой генератора.
И в чем разница? Неассоциативные массивы обычно нужны, чтобы обработать их через foreach. Большинство читателей знают значение слова "контекст", и подразумевают foreach по умолчанию.
Это не эквивалентное действие. С изменением контракта в вызывающем коде появится новый цикл. Вы не сможете изменить контракт и не менять структуру вызывающего кода.
не оборачивать в функцию
Не оборачивать в функцию что конкретно? Код, который не загружает все данные для цикла сразу, то есть экономит память.
датапровайдеры в тестах удобнее на генераторах
Это просто побочный эффект одного из кейсов использования, который при желании можно решить и без генератора.
создание итератора с сложной логикой, которая менее неудобна при формировании полного массива.
Да ничего вам не мешает вместо yield складывать в массив и возвращать его из функции, чтобы вызывающий код вместо сложной логики сделал простой foreach.
посмотрите статью про генераторы и корутины
"Таким образом вы можете работать с очень большими наборами данных, не загружая их всех в память."
Я сильно сомневаюсь, что разработчики языка планировали имитацию многопоточности как основное назначение генераторов. Я вообще не вижу у корутин конкретно в PHP возможного практического применения.
люди видят в генераторах только 1 использование
Ваш изначальный вопрос был в другом. "Почему генераторы ассоциируют всегда с экономией памяти?"
"A generator offers a convenient way to provide data to foreach loops without having to build an array in memory ahead of time, which may cause the program to exceed a memory limit"
Как видите, сами разработчики языка говорят, что это способ использовать меньше памяти.
Я попробую последний раз, дальше повторять не вижу смысла. Генератор экономит память именно потому что он содержит код, который читает из потока по одной ложке. Без этого они нафиг не нужны.
генератор - это про обернуть
Чтобы обернуть, есть обычные функции. Это будет просто обычная функция, которая возвращает массив.
А вот вы напишите вызывающий код полностью, а не с магическим "process data", тогда и будет понятно зачем.
fgetcsv И никаких генераторов не нужно!
fgetcsv внезапно работает аналогично генератору. И у вас handle опять сам магически откуда-то появляется. Если вы захотите поместить логику его получения и закрытия в отдельную функцию, чтобы ее не было в коде с циклом, то без генераторов вам надо будет загружать все строки в память.
Ну то есть он был прав?
Как быть с доступностью, если ДБО "легло" на плановое обслуживание или из-за инцидента?
То есть вы еще ничего не внедрили, не проверили как это будет работать в реальных процессах, а уже побежали на Хабр рассказывать?
В тот, в который звуковой рецептор дает импульс. Это сводится к вопросу о количестве молекул в разных взаимодействиях, то есть к дискретным частям.
Будет. Это аналогично вопросу "Если в галактике, где никого нет, взорвалась звезда, будет ли свет?".
По наблюдениям мы знаем, что он будет, и будет идти по Вселенной миллионы лет.
Это утверждение не доказано.
Нет, вывод должен быть, что к существующим вещам не всегда можно добавить новые.
Нет, внутри самой вещи разделение не требуется.
Даже "между ними должно быть нечто иное" не требуется, достаточно, чтобы другая вещь была чем-то иным, чем первая.
Но это поднимает вопрос границы, где именно заканчивается одна вещь и начинается другая.
Нет, вывод в том, что каждая часть вещи не может делиться до бесконечности.
Необязательно. Можно предположить, что Вселенная это и есть такое пространство. Можно предположить, что они просто есть как первичная сущность, которой не нужно своё пространство. Можно предположить, что просто вещи двигаются в пространстве на дискреты, а сами дискреты как физическая сущность не существуют.
Это неправильный вывод. Даже если у них одинаковые собственные характеристики, они могут различаться положением в пространстве, так что их может быть много.
Выглядит так, что все апории Зенона разрешаются введением квантов.
Ахиллес догонит черепаху только потому, что проходит 1 квант пространства за меньшее количество квантов времени.
Нет, логически есть реальные предметы со своими различиями и есть их наблюдение, и это не одно и то же. Так же как исходный предмет и его фотография. Фотоаппарат может не делать фотографию предмета, но предмет от этого не исчезает.
Вы путаете сознание и интеллект. Они связаны, но это не одно и то же. Если любое различение приписывать сознанию, то не останется ничего, что можно приписать функциональности интеллекта.
Ну вам может и мешает, не надо говорить за других.
Нет, вполне может быть так, что эти отличительные признаки в данный момент никто не наблюдает. Но они могут оставить следы, которые потом будет наблюдать кто-то другой.
Это неверное утверждение. Мир устроен, просто может быть так, что никто не воспринимает его устройство.
Взрывы сверхновых произошли миллионы лет назад, когда еще не было осмысливающих наблюдателей, а воспринимаем мы их только сейчас. Значит миллионы лет назад мир уже был устроен в виде звезд.
Я вам уже доказал со ссылкой на документацию, что это утверждение ложно. Меньший расход памяти в определенных операциях является основной причиной их добавления.
Непонятно, что вы имеете в виду. Обычная функция может возвращать массив, который можно использовать в foreach.
Вообще у вас как-то слишком много предположений для того, что в этой ветке заявляется как основное назначение генератора.
И? Там есть предложение написать этот код. Мое высказывание это возражение на это утверждение, а не ответ на какой-то вопрос. Не все высказывания являются ответами на вопросы.
Имеет. Если вы его не поняли, это не значит, что его нет.
Это указание на то, что предложение "Извлекаете порциями и сохраняйте после извлечения" и так всем понятно, и это оно не имеет смысла.
Затем, чтобы не менять вызывающий код, в котором уже написан foreach. Или не усложнять, если еще не написан.
Дал, просто вы невнимательно читаете.
А в этой ветке этот ответ не нужен.
Нет, это уже оптимизация базового алгоритма.
Он имеет отношение к генераторам. В контексте которых написан исходный комментарий.
Не вырвал из контекста, а показал, что это глупый вопрос. Если бы он был задан как-то по-другому, то возможно он не выглядел бы глупо. Из файла нужно извлечь миллион записей и все их сохранить в БД, нет смысла спрашивать зачем.
Ну вот так и надо было спрашивать.
Есть, если памяти достаточно, проще сделать функцию, которая извлекает из файла сразу все данные, и не возиться с генератором.
Я вас уже спрашивал, в чем вы видите разницу, вы не ответили. Видимо ответа у вас нет.
Естественно, при использовании foreach, большие объемы данных обычно обрабатывают через foreach. Он подразумевается по контексту. И нет, генераторы можно использовать и в других циклах.
Ну так это и есть основной сценарий использования генераторов.
Нет не должен, мне нафиг не надо раскидывать эти детали реализации в вызывающем коде по всему приложению. Я сделал функцию query именно затем, чтобы их туда спрятать.
Это не легко увидеть, потому исходный цикл остался в вызывающем коде, который вызывает вашу getOrders(). Вы опять использовали логическую манипуляцию и привели пример кода не полностью. Если бы исходный цикл стал основой генератора, то он бы не остался в вызывающем коде.
Спесь проявляете тут вы. Оскорбляете других и применяете логические манипуляции, чтобы иметь хотя бы какое-то обоснование высокомерного поведения. Игнорируете прямое объяснение из документации от разработчиков языка, зачем нужны генераторы. Там прямым текстом написано, что назначение генераторов - уменьшить расход памяти в приложении. На этом можно закончить.
Это полностью неверное утверждение. Это не является ни назначением генератора, ни описанием его работы.
Чтобы результат любого цикла представить в виде массива, можно просто складывать в массив, генератор для этого не нужен. Поэтому делали его для другого.
А в виде массива (одномерного) он представляет не "результаты цикла", а значения после оператора yield. Которые могут быть в одном цикле, в нескольких вложенных циклах, или вообще без циклов.
Да ни при чем тут исходный цикл. Для экономии памяти генератор не оборачивает исходный цикл, а добавляет новый.
Исходный цикл:
Цикл с генератором:
Исходный цикл как был так и остался, а не стал основой генератора.
Ну так генератор это и есть место, чтобы поместить туда этот код, сохраняя простой foreach в вызывающем коде.
Потому что бизнес-требования такие?
Для этого вам не нужен генератор, ждать может и обычная функция.
И в чем разница? Неассоциативные массивы обычно нужны, чтобы обработать их через foreach. Большинство читателей знают значение слова "контекст", и подразумевают foreach по умолчанию.
А для чего он по-вашему?
Это не эквивалентное действие. С изменением контракта в вызывающем коде появится новый цикл. Вы не сможете изменить контракт и не менять структуру вызывающего кода.
Не оборачивать в функцию что конкретно? Код, который не загружает все данные для цикла сразу, то есть экономит память.
Это просто побочный эффект одного из кейсов использования, который при желании можно решить и без генератора.
Да ничего вам не мешает вместо yield складывать в массив и возвращать его из функции, чтобы вызывающий код вместо сложной логики сделал простой foreach.
"Таким образом вы можете работать с очень большими наборами данных, не загружая их всех в память."
Я сильно сомневаюсь, что разработчики языка планировали имитацию многопоточности как основное назначение генераторов. Я вообще не вижу у корутин конкретно в PHP возможного практического применения.
Ваш изначальный вопрос был в другом. "Почему генераторы ассоциируют всегда с экономией памяти?"
https://www.php.net/manual/en/language.generators.overview.php
"A generator offers a convenient way to provide data to foreach loops without having to build an array in memory ahead of time, which may cause the program to exceed a memory limit"
Как видите, сами разработчики языка говорят, что это способ использовать меньше памяти.
Именно что имеет. Иначе зачем вам продолжать с того же места?
Генератор, который не служит для экономии памяти и не имеет этого цикла, низачем не нужен.
Это прекрасно достигается обычной функцией, которая возвращает массив. В одном месте получили массив из базы, в другом его обработали.
Я попробую последний раз, дальше повторять не вижу смысла. Генератор экономит память именно потому что он содержит код, который читает из потока по одной ложке. Без этого они нафиг не нужны.
Чтобы обернуть, есть обычные функции. Это будет просто обычная функция, которая возвращает массив.
Генератор сохраняет состояние, чтобы при повторном обращении продолжить с того же места, а не сначала. fetch именно так и работает.
А вот вы напишите вызывающий код полностью, а не с магическим "process data", тогда и будет понятно зачем.
fgetcsv внезапно работает аналогично генератору.
И у вас handle опять сам магически откуда-то появляется. Если вы захотите поместить логику его получения и закрытия в отдельную функцию, чтобы ее не было в коде с циклом, то без генераторов вам надо будет загружать все строки в память.
Тут используются те же механизмы, что и в генераторе.