R
Балком!
Size: a a a
2021 April 13
DF
Да, запрос проверки наличия данных был быстрый, а вот выборка долгая
a
Кто же говорит, что это запрещено? Но на практике это _обычно_ не применяется.
R
Вы же и говорите. "так никто не пишет"
a
Так это же не "закончились ли данные в итераторе или нет".
DF
чойта? Оно самое и есть. Классический lazy итератор, ничего не делает пока next не дернешь
R
На читаемость программы, как следствие, на ее сопровождаемость, больше влияет стиль изложения, чем применяемые паттерны и приемы.
a
Нет, ну можно взять ту же репу, которую я привёл, - и сказать: вот пример, что пишут. Но на практике, сколько я повидал реального кода, такое оочень редко делали.
a
Так ведь что бы обленивить что угодно, достаточно его в лямбду обернуть: sub { $iter->next }
Зачем для этого 2 запроса делать? Просто звучит как то, что у вас был API, не связанный с итерацией, но вы его использовали через итератор.
И ещё вопрос: а другие итераторы при этом у вас были? И код, работающий на итераторах, не знающих, как устроен конкретный итератор?
Зачем для этого 2 запроса делать? Просто звучит как то, что у вас был API, не связанный с итерацией, но вы его использовали через итератор.
И ещё вопрос: а другие итераторы при этом у вас были? И код, работающий на итераторах, не знающих, как устроен конкретный итератор?
a
Ну, вот был опыт сопровождения проги, где паттерны GoF применялись к месту и не к месту - воспринимать её было очень сложно.
DF
Потому что запрос
count(id) .. offset n сильно быстрее чем ебический джойн на полтора экрана. Апи естественно никак не связано с итерацией, это был грязный хак прикрученый сбоку базе данных. В которую за время обработки еще данных налиться успевало. Считать разом в память было нельзя, потому что в память тупо не лезло. Короче это было дендрофекальное решение, но в реальном мире такое бывает достаточно часто.a
Просто я не понимаю: если вам надо было обойти все найденные данные в любом случае, почему не работала реализация с одним ->next ?
(внутри она, конечно, могла быть реализована через последовательные 2 запроса к внешней системе).
(внутри она, конечно, могла быть реализована через последовательные 2 запроса к внешней системе).
DF
Вот тут уже не помню, лет 10 назад дело было. Сначала все было написано с одним ->next, потом переписали на два запроса. Возможно просто админы ругались :)
a
Просто звучит так, как у вас было просто, условно:
while (X) { do_something_with( Y ); }
и вы отрефакторили X как has_next, а Y - get_next - но это _не_ паттерн Iterator. Он подразумевает то, что у вас есть код, который ничего не знает о вашем коде, а только об интерфейсе итератора. И вот обычно для этого достаточно одного next, который возвращает undef при завершении...
while (X) { do_something_with( Y ); }
и вы отрефакторили X как has_next, а Y - get_next - но это _не_ паттерн Iterator. Он подразумевает то, что у вас есть код, который ничего не знает о вашем коде, а только об интерфейсе итератора. И вот обычно для этого достаточно одного next, который возвращает undef при завершении...
DF
Ну здрасьте, а что это? Итератор в чистом виде.
a
Просто декомпозиция логики на 2 процедуры. Вот если бы, например, у вас такие итераторы были например для набора внешних сервисов, и у вас был бы общий код, который работал с ними всеми, то это Итератор.
Iterator is a behavioral design pattern that lets you traverse elements of a collection without exposing its underlying representation (list, stack, tree, etc.)
А вот структурные паттерны: https://refactoring.guru/design-patterns/structural-patterns
Iterator is a behavioral design pattern that lets you traverse elements of a collection without exposing its underlying representation (list, stack, tree, etc.)
А вот структурные паттерны: https://refactoring.guru/design-patterns/structural-patterns
DF
Что-то не улавливаю логики: в жабе nas_next next это итератор, а в перле нет :) То, что у меня в коде других таких итератеров не было ничего не значит, у меня в коде в принципе других итераторов не было :)
DF
Т.е. я не спорю с тем, что это не каноничный синтаксис для перла в 99% случаев.
DF
Но говорить что из-за этого объект перестал быть итератором это странно, как по мне
c
~ raku -e '<a b c>.iterator.pull-one.say'
a