Комментарии 17
нам нужно обойти дерево неизвестной глубины. Классическое решение — рекурсия.
я тут недавно выяснил(ищите по слову "рекурсия"), что вместо рекурсии теперь модно использовать новый термин "stack dives".
мне кажется, если ООП подход позволяет избавится от рекурсии, это уже само по себе неплохо.
Простите, это сильно отличается от ношения бирки с кличкой и адресом домашнего животного на ошейнике? Мне для интеллектуального развития надо.
я тут недавно выяснил(ищите по слову "рекурсия"), что вместо рекурсии теперь модно использовать новый термин "stack dives"
Интересно, не слышал об этом. Хотя насколько я понял, stack dives в этом контексте - скорее идентификация потенциальной проблемы, нежели синоним для рекурсии, которая просто является инструментом.
если ООП подход позволяет избавится от рекурсии, это уже само по себе неплохо.
И правда, но в данном случае это скорее приятный побочный эффект, избавляться от любой рекурсии таким способом несколько экстравагантно :)
Сама задача развёртывания рекурсии всё же не новая и решается своими способами, которые легко находятся на хабре.
Максим написал рекурсивный алгоритм, и столкнулся со Stack Overflow exception.
мне кажется что даже "Stack Overflow", в каком-то смысле, можно считать синонимом рекурсии. По крайней мере, именно по этой причине я бы не рекомендовал ее применение.
С точки зрения производительности рекурсия постоянно вводит в работу новую память, что крайне негативно сказывается на производительности на платформах с аппаратным кешем памяти.
Разумеется, есть 1001 и 1 причина рекурсию не использовать, хотя этим тоже связана разная магия.
Я просто о точности понятий, а то приравнивать StackOverflow и рекурсию, это как равнять программирование и производство багов — вроде одно без другого и не бывает, но вещи всё же разные :)
Если stack dives это рекурсия, то рак лёгких это курение, а похмелье это пьянство. Хватит цепляться к словам, которые вы не поняли, и делать далеко идущие выводы на пустом месте.
как известно аналогии всегда неполноценны. Вы бы объяснили толком, почему вы считаете, что stack dives это НЕ рекурсия. Мне действительно интересно как можно обосновать такую точку зрения, что нельзя заменить "stack dives" на "рекурсия"!
Как вы понимаете stack dives и в каком контексте?
Заранее спасибо за аргументированную позицию.
Потому что это не рекурсия, а явление, иногда возникающее при рекурсии (в том числе).
Выконечно правы что stack dives это результат рекурсии, а не сама рекурсия.
Интересно что даже ваши аналогии очень показательны. Конечно похмелье и пьянство это разные вещи, хотя одно является результатом другого. Но если говорить о лечении то будет не очень умно лечить похмелье, согласитесь, так как надо лечить причину.
Да, я пользуюсь именно этим приемом, я пытаюсь переключить внимание с последствий на причину, с того что имеется ввиду под stack dives на прямую неконтролируемую рекурсию, которая является причиной этого stack dives.
В связи с этим мне не совсем понятно ваше слишком эмоциональное отношение к этому, в общем то техническому приему переключения внимания с последствий на причину, которое мне кажется в таком контексте, вполне оправданным.
Да, я пользуюсь именно этим приемом, я пытаюсь переключить внимание с последствий на причину, с того что имеется ввиду под stack dives на прямую неконтролируемую рекурсию, которая является причиной этого stack dives.
Да правда что ли? Ну так найдите тогда прямую рекурсию вот в этом коде:
async Task Foo(int i) {
using (await asyncMutex.Lock()) {
Console.WriteLine($"Task completed: {i}");
}
}
Что же до непонятного эмоционального отношения - я его наблюдаю у вас. Хороший специалист поделился своими знаниями с читателями - а вы у него вычитали два слова и начали его в чём-то непонятном обвинять.
Какое же ООП многословное и тяжёлое
Стратегию ака внедрение зависимости от функции делать в ООП лучше когда оно реально понадобится а не когда может быть понадобится.
А лучше писать в функциональном стиле, тогда и шаблон стратегия будет удобным
https://youtu.be/ipceTuJlw-M?si=GyekQMTGj-4gCX65
Особенно прикольно на 35 минуте fizzbuzz расширяемый через стратегию
Стратегию ака внедрение зависимости от функции делать в ООП лучше когда оно реально понадобится а не когда может быть понадобится.
Согласен, в масштабах одной задачи это и правда выглядит избыточно. С моей стороны стимулом всё же было превентивно отделить мух от котлет (ибо в данном случае задача поиска объявления переменных кажется слишком специфичной, если сравнивать её с раскрытием операторов).
А лучше писать в функциональном стиле, тогда и шаблон стратегия будет удобным
Ох, это же сам F# в видео! Всегда интересно про функциональщину слушать, но до дела (и у меня, и глобально) всё никак не доходит :/
По каким причинам в качестве промежуточного представления было выбрано синтаксическое дерево? Исключительно из-за простоты построения? Не дала бы выигрыша работа с трёхадресным кодом или представлением, основанным на классах? По ощущению это позволило иметь больше контекста для распознавания тех или иных паттернов в коде.
Применение ООП на практике