Вверх ↑
Ответов: 9906
Рейтинг: 351
#1: 2014-01-20 12:37:43 ЛС | профиль | цитата
nesco писал(а):
В принципе, это и есть рекурсивность интерфейса

В принципе, это не рекурсивность интерфейса, а павлино-утко-еж

Вообще-то рекурсия началась в структурном программировании, и получила широкое развитие в функциональном. И корректность рекурсии основана на том, что вызов функции не имеет побочных эффектов. Это основополагающее требование для корректности рекурсии. Иначе это называется требованием реентерабельности.
Это как раз та фишка, которую не понимал коллега Tad, ошибочно утверждая (было дело), что достаточно того - чтобы она закончилась.
Недостаточно, тут коллега был категорически неправ.

Чем достигается корректность рекурсии в структурном программировании. Тем, что функция работает только с памятью, которая расположена в стеке: аргументы и локальные переменные. Ровно в тот момент, когда локальную переменную сделают глобальной - все это может легко перестать работать.
Так вот: в классической рекурсии на каждом уровне выделяется новая память. В стеке - это побыстрее, конечно же, чем в хипе, но - обязательно ВЫДЕЛЯЕТСЯ.

В функциональном программировании - это вообще родное. Там принимается в качестве аксиомы, что ни одна функция не обладает возможностью побочных эффектов. Само слово - "переменная", является у них запрещенным.
В моем представлении, объектно-ориентированное программирование (можно даже сказать, что HiAsm является его визуализацией) является антиподом функционального программирования.
У нас не просто есть слово "переменная", а оно обобщено до квинтэссенции этой концепции, и называется объект.
А т.н. "побочное действие" - это просто изменение состояния объекта. Это как раз то, на чем мы строим наши алгоритмы.
У нас (в ООП) это не "побочное", а основное действие, ради которого этот объект, вообще-то говоря, и замышлялся.

Ну вот, либо так, либо как у функциональщиков - думать "задом наперед"
Мне больше нравится - ТАК.

Какой из этого вывод: мы не можем, вообще-то говоря - потребовать реентерабельности методов объекта. Это просто противоречит нашей концепции. Следовательно, кольцевание - это табу.
Но, рекурсивные задачи никуда не исчезли, умеем ли мы решать таковые в концепции ООП.
Умеем. Созданием динамического объекта, вызовом нужных его методов, с последующим уничтожением.

nesco, можешь себе представить, я это пробовал. Здесь на форуме.
Когда-то, когда "линки" только появились, Dilma разрешал их рекурсивное использование. И я тут же попробовал сортировку массива.
Идея была такая: получивши массив с верхней точки, я создавал два других (вдвое меньшей длины) запускал (сортировал) два мультика (это и были рекурсивные линки на самого себя)в режиме OnlyOnce, и из этих двух отсортированных половинок - перезаписывал входной (который я с самого начала взял с верхней точки).

Да, можешь себе представить, на каждом уровне рекурсии (а таковых LOG(N)) аллоцируется память. Так она и в классическом структурном программировании аллоцировалась.

Где-то на форуме была схема. И она работала: асимптотика была N*LOG(N).
Да, для учета эдаких рекурсий пришлось модифицировать кодогенератор. И я это сделал. Успел
А вот Dilma проблему с линками так и не разрулил. И просто запретил рекурсивные линки. На долгие времена.

Хотя, у меня есть подозрение, что сейчас они снова разрешены... Но руку на отсечение не дам.

карма: 9

0