Если вы имели в виде «бесконечный», то Backward как раз производит очень даже конечный итератор — ведь он обходит срез, а тот имеет фиксированную длину (на момент начала обхода).
Автор в курсе, что такое срез :) Менять in-place нельзя, Backward не должна менять исходные данные. Поэтому если создавать новый срез, то это make() на N элементов, и O(n) памяти — как в первом примере. Все прочие примеры уже O(1).
Пожалуйста, не пишите так на Go. Оставьте эту дрянь для джавы. Решайте реальные задачи вместо построения сферических коней в вакууме — и обнаружите, что они прекрасно решаются простыми средствами. Например, через замыкание.
var nCalls = 0
func count(fn func()) {
fn()
nCalls++
}
func main() {
sum := func(a int, b int) int {
return a + b
}
total := 0
count(func() { total += sum(1, 2) })
count(func() { total += sum(3, 4) })
count(func() { total += sum(5, 6) })
fmt.Println(total)
// 21
fmt.Println(nCalls)
// 3
}
Это как раз ясно. Я о том, что мне не близок вот этот подход:
Можно было бы применить копипасту или кодогенерацию, но тот червь, что живет в моем мозгу, опять начал зудеть и нашептывать что-то про дженерики, не давая спать по ночам.
Простое решение было, но вы его не выбрали. А выбрали вот это, где дженерик на дженерике сидит и дженериком погоняет. Я за то, чтобы в продакшене такого кода было как можно меньше.
Мы хотим поддержать частных авторов, желающих рассказывать о своих коммерческих проектах
С удовольствием платил бы какие-то вменяемые деньги за право ставить ссылку на свои платные проекты в статьях. Для инди-разработчиков существующие тарифы Хабра — заградительные.
Вообще я планировал небольшую заметку, но не преуспел: получилась здоровенная статья. Старался выбрать только самое интересное, но все равно в обзор попало три десятка доработок. Питон, он такой ツ
Я не знаю, зачем вы sql используете. Но если используете, то это вариант. Странно предъявлять претензии sqlite, что он не умеет как монга (она нереляционная), а на предложение использовать нереляционные фичи sqlite спрашивать «а зачем тогда вообще sql».
Чтобы его можно использовать для обхода карты, например — где ключ не обязательно int.
Если вы имели в виде «бесконечный», то Backward как раз производит очень даже конечный итератор — ведь он обходит срез, а тот имеет фиксированную длину (на момент начала обхода).
Автор в курсе, что такое срез :) Менять in-place нельзя, Backward не должна менять исходные данные. Поэтому если создавать новый срез, то это make() на N элементов, и O(n) памяти — как в первом примере. Все прочие примеры уже O(1).
Если бы автор так яростно не кривлялся, статья была бы лучше.
Пожалуйста, не пишите так на Go. Оставьте эту дрянь для джавы. Решайте реальные задачи вместо построения сферических коней в вакууме — и обнаружите, что они прекрасно решаются простыми средствами. Например, через замыкание.
песочница
Да, в основном страдали только в первый раз. Но зато все :)
(и не будет)
—
GPT-4, перелогиньтесь!
А начиная с версии 3.37 типы полей и вовсе не проблема, потому что можно использовать STRICT-таблицы.
Это как раз ясно. Я о том, что мне не близок вот этот подход:
Простое решение было, но вы его не выбрали. А выбрали вот это, где дженерик на дженерике сидит и дженериком погоняет. Я за то, чтобы в продакшене такого кода было как можно меньше.
Вот поэтому не все в сообществе были рады появлению дженериков. Потому что понимали, что немедленно найдутся люди, которые будут писать код так:
А нам потом это поддерживать.
Ну зачем так делать? Go задумывался как простой язык. Да, многословный. Но простой. Пожалуйста, не пишите на нем как на джаве.
С днём рождения!
С удовольствием платил бы какие-то вменяемые деньги за право ставить ссылку на свои платные проекты в статьях. Для инди-разработчиков существующие тарифы Хабра — заградительные.
Зависит от реализации. Если новая функция написана на C — будет работать быстрее, чем ваша самописная на Python. Если нет — возможны варианты.
А теперь можно сохранять и делиться ссылками без регистрации.
Вообще я планировал небольшую заметку, но не преуспел: получилась здоровенная статья. Старался выбрать только самое интересное, но все равно в обзор попало три десятка доработок. Питон, он такой ツ
Я не знаю, зачем вы sql используете. Но если используете, то это вариант. Странно предъявлять претензии sqlite, что он не умеет как монга (она нереляционная), а на предложение использовать нереляционные фичи sqlite спрашивать «а зачем тогда вообще sql».
Например, так
Почему нельзя сделать одно общее поле для данных в таблице messages?
Спасибо! Мне больше нравится без подсветки синтаксиса. Без регистрации на гитхабе никак, к сожалению.