Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

G>>>>2)Этот код работает лениво, в отличие от твоего
I>>>И ты уверен, что всегда нужна эта ленивость ?
G>>Там где не нужна будет я напишу ToList, а ты что сделаешь чтобы получить ленивость в своем коде ?

I>Ты свой код сам писал ? foreach что у тебя делает ? Опаньки, ленивость вышла кастрированая
Ты о чем вообще? Нормальная там ленивость. Ты настолько плохо разбираешься в итераторах?

I>Но вообще ленивость в моем случае всегда замедление, что недопустимо в принципе.
Придать "энергичность" ленивому коду легко, наоборот — нет.


G>>>>Приведи пример, тогда посмотрим.

I>>>Слишком большой пример получается а ты постоянно спрыгиваешь на свои задачи.
G>>Да ну?
G>>Ты привел код, а когда я привел свой вариант, делающий ровно тоже самое, но с большим потенциалом повторного использования и композиции ты сказал:
I>А для чего в частном случае целая куча кода как у тебя да еще с сайд-эффектами в виде недоленивости и проседания перформанса ?
Ладно, то что ты не понимаешь C# кое-где я уже понял. И сайд-эффектами ты тоже называешь непонятно что.
Кроме того ты совершенно не к месту притянул перформанс. Надо бы его померить, а потом говорить.

G>>А до этого пытался оправдать непонятно зачем написанный недовизитор тем что у тебя "еще куча всего".
I>И что тебя смущает ? Код завязан на определенную специфику и нет времени адаптировать его персонально для тебя.
Я тебе показал более общий код, который делает тоже самое

G>>Более того, ты завел разговор о визиторах, хотя зачем там визиторы — так и не смог показать.
I>Выполнять операции над конкретной структурой, это ж очевидно. В операциях оных всегда нужен обход какой нибудь.
Так ты и не показал визитор, показал рекурсивную функцию с замыканием.

I>>>Это частный случай который больше никуде не приспособить
G>>2)Он позволяет обойти любое дерево, где узел хранит ссылки на потомков
I>Твой вариант удобен только для однородной структуры, т.е. частный случай.
Я привел пример в соответствие с твоим кодом.

G>>3)Так как обход делается лениво, то это позволяет без проблем комбинировать его с другими

I>Во первых, ленивость у тебя кастрированая.
Не говорил бы глупостей.

I>Во вторых, у тебя частный случай.
Более общий, чем ты привел.

I>В третьих проблемы в виде проседания перформанса в несколько раз.
Мерить надо.

I>В четвертых, гнусная отладка получается с твоими "комбинаторами".
А думаешь с рекурсивными вызовами анонимных функций, что ты привел, получается проще.

Хочешь что-то показать — приводи реальный код. А так все мои высказывания опираются на то что ты привел. Если то что ты привел не соотвествует тому что ты делаешь на самом деле — твои проблемы.

А так ты фигню морозишь по полной.

Здравствуйте, gandjustas, Вы писали:

I>>Ты свой код сам писал ? foreach что у тебя делает ? Опаньки, ленивость вышла кастрированая
G>Ты о чем вообще? Нормальная там ленивость. Ты настолько плохо разбираешься в итераторах?

Да, я сегодня не выспался шота Есть ошибка, которая вобщем то и у меня в наличии — HashSet нужен для завершения рекурсии.
Тебя, вероятно ввело в заблуждение слово Childs, правильнее назвать Connections.
Вот, нужно добавить:

Visitor<Vertex> visit = (v) => {if(hash.Contains(v)) return; hash.Add(v); visitList(v.Childs); };

Назначение функции — вычислить подграф c определенным порядком следования вертексов, для чего используется модифицированый dfs

I>>В третьих проблемы в виде проседания перформанса в несколько раз.
G>Мерить надо.

Уже измерено. Разброс есть, правда не такой, как говорит Дворкин, но есть и это очень неприятно, т.к. все это влияет на время отклика.

I>>В четвертых, гнусная отладка получается с твоими "комбинаторами".
G>А думаешь с рекурсивными вызовами анонимных функций, что ты привел, получается проще.

Конечно проще, весь обход — перед глазами.

G>Хочешь что-то показать — приводи реальный код. А так все мои высказывания опираются на то что ты привел.

Вот фунцыя, находит все роуты в подграфе вершиной которого является root, снова модифицированый dfs. Покажи мне Linq и Комбинаторы

IEnumerable<Route> AllRoutes(Vertex root)
{
   var hash = new HashSet<Vertex>();
   var route = new List<Vertex>();
   var routes = new List<Route>();

   ListVisitor<Vertex> visitList = null; 
   Visitor<Vertex> visit = (v) =>  
   {  
     if(hash.Contains(v)) 
     {
        routes.Add(new Route(route));
        return; 
     }
     route.Add(v);        
     hash.Add(v); 
     routes.Add(new Route(route));
     visitList(v.Childs); 
     route.RemoveLast(); // как ты это обойдешь, не ясно
   };
   visitList = (l) => { foreach(var v in l ?? new Vertex[0] ) visit(v); }

   visit(root);

   return routes;
}

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Это не паттерн Visitor, а какая то фигня. Паттерн используется, когда нужна диспетчеризация по типам с общим корнем.

На статическом полиморфизме визитор тоже прекрасно работает, например в С++.

Здравствуйте, Ikemefula, Вы писали:

I>С таким подходом вообще все получается цельнотянутым из ФП

ВЫ неправильно делаете, что обсуждаете какие-то цитаты. Не важно, откуда взялась идея начального дизайна, важно, какой дизайн вышел в итоге. Он вышел в стиле ФП, кто бы что ни говорил. И библиотеки буста тоже по большей части идут в ФП стиле.

Здравствуйте, Ikemefula, Вы писали:

I>Вообще говоря визитор это не только когда диспетчеризация по типам с общим корнем.

Вообще говоря только. По определению.

... the visitor allows one to add new virtual functions to a family of classes without modifying the classes themselves; instead, one creates a visitor class that implements all of the appropriate specializations of the virtual function. The visitor takes the instance reference as input, and implements the goal through double dispatch.

Википедия

А вот откуда взялось поверье, что визитор это обход графа для меня загадка.

Здравствуйте, vdimas, Вы писали:

НС>>Это не паттерн Visitor, а какая то фигня. Паттерн используется, когда нужна диспетчеризация по типам с общим корнем.

V>На статическом полиморфизме визитор тоже прекрасно работает, например в С++.

Статический полиморфизм это уже не визитор, и даже не может являтся его заменой. Как не может статическая перегрузка методов быть заменой мультиметодов.
Откуда вообще эта стратсть натягивать презерватив на ежика? Визитор — вполне конкретный паттерн, описанный изначально в GoF. При этом может существует несколько видов задач диспетчеризации и несколько методов решения этих задач, но визиторами они от этого не становятся.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Откуда вообще эта стратсть натягивать презерватив на ежика?
Так оно круче звучит и создаёт иллюзию безопасного ёжика понимания предмета.

Здравствуйте, Ikemefula, Вы писали:


I>>>В четвертых, гнусная отладка получается с твоими "комбинаторами".
G>>А думаешь с рекурсивными вызовами анонимных функций, что ты привел, получается проще.

I>Конечно проще, весь обход — перед глазами.

Только непонятно нифига. А обобщенный комбинатор пишется и отлаживается ровно один раз.

G>>Хочешь что-то показать — приводи реальный код. А так все мои высказывания опираются на то что ты привел.

I>Вот фунцыя, находит все роуты в подграфе вершиной которого является root, снова модифицированый dfs.
Кто такие роуты? В твоем коде черт ногу сломит. Рекурсия + mutable state читаемость снижают до нуля.

Здравствуйте, gandjustas, Вы писали:

G>И чем он оправдан там где сложность?
G>Скорее наоборот. Сложность реализации простых вещей оправдывается языком C++, но при этом во всю говорят о том как это эффективно.

Почему, когда другие языки имитируют (обычно с потерей эффективности) фичи C++, такие как метапрограммирование, переопределение операторов,
объекты STL — это "круто", а С++ "слишком сложный"?
Черт возьми, ну не для всех он "слишком сложный"...

Здравствуйте, Head Ache, Вы писали:

HA>Здравствуйте, gandjustas, Вы писали:

G>>И чем он оправдан там где сложность?
G>>Скорее наоборот. Сложность реализации простых вещей оправдывается языком C++, но при этом во всю говорят о том как это эффективно.

HA>Почему, когда другие языки имитируют (обычно с потерей эффективности) фичи C++, такие как метапрограммирование, переопределение операторов,
С чего это переопределение операторов — фича C++? Эта фича во многих языках была и до C++ и есть во многих после.

HA>объекты STL — это "круто", а С++ "слишком сложный"?

STL как раз упрощает C++: по-максимуму прячет указатели, реализацию строк и работу с динамической памятью. Это как раз те аспекты С++, которые делают его переусложненным.

Здравствуйте, vdimas, Вы писали:

V>ВЫ неправильно делаете, что обсуждаете какие-то цитаты. Не важно, откуда взялась идея начального дизайна, важно, какой дизайн вышел в итоге. Он вышел в стиле ФП, кто бы что ни говорил. И библиотеки буста тоже по большей части идут в ФП стиле.

ФП-стиль это баззворд.

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Вообще говоря визитор это не только когда диспетчеризация по типам с общим корнем.

НС>Вообще говоря только. По определению.

Чушь. Открываешь любую книгу и читаешь — операции над объектной структурой. Общий корень может быть а может и не быть. А вот двойная диспетчеризация будет обязательно.

НС>Википедия

После таких аргументов ... Но если ты прочтешь тобой же написано, то окажется, что общий корень вовсе необязательно.

НС>А вот откуда взялось поверье, что визитор это обход графа для меня загадка.

Процитируй, уважаемый Трепло, где же я такое сказал.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Статический полиморфизм это уже не визитор, и даже не может являтся его заменой.

Википедию поменьше читай.

НС>Откуда вообще эта стратсть натягивать презерватив на ежика? Визитор — вполне конкретный паттерн, описанный изначально в GoF.

В ГОФ он изложен достаточно гнусно, как и многие другие паттерны.

Здравствуйте, Ikemefula, Вы писали:

I>Чушь. Открываешь любую книгу и читаешь — операции над объектной структурой

Под это определение подходят чуть болеечем все поведенческие паттерны
Ну да цитату в студию. Лучше всего из банды, первоисточник все таки.

I>. Общий корень может быть а может и не быть. А вот двойная диспетчеризация будет обязательно.

С точностью до наоборот.

I>После таких аргументов ...



I> Но если ты прочтешь тобой же написано, то окажется, что общий корень вовсе необязательно.

В общем случае — нет, в шарпе — обязателен (до C# 4 по крайней мере). Потому что для общего виртуального метода необходим общий корень.

НС>>А вот откуда взялось поверье, что визитор это обход графа для меня загадка.

I>Процитируй, уважаемый Трепло, где же я такое сказал.

Я не про тебя, неуважаемое Хамло.

Здравствуйте, gandjustas, Вы писали:

I>>Конечно проще, весь обход — перед глазами.

G>Только непонятно нифига. А обобщенный комбинатор пишется и отлаживается ровно один раз.

Я и вижу — ошибку в своем коде ты не смог пофиксить

Комбинаторы нужны, только от linq в конкретном примере толку не будет. Комбинатор, который фильтрует роуты которые поглощают другие роуты вполне пригодится но это опять же без linq.

G>>>Хочешь что-то показать — приводи реальный код. А так все мои высказывания опираются на то что ты привел.

I>>Вот фунцыя, находит все роуты в подграфе вершиной которого является root, снова модифицированый dfs.
G>Кто такие роуты? В твоем коде черт ногу сломит. Рекурсия + mutable state читаемость снижают до нуля.

Там все очевидно, если ты знаешь что такое dfs. В данном случае mutable state не вносит никакой проблемы/

И заметь — как дело дошло до реального примера, ты в очередной раз сдулся. На будущее — не проси у меня примеров кода.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

I>>>Конечно проще, весь обход — перед глазами.

G>>Только непонятно нифига. А обобщенный комбинатор пишется и отлаживается ровно один раз.

I>Я и вижу — ошибку в своем коде ты не смог пофиксить
Где там ошибка, ткни пальцем.

G>>>>Хочешь что-то показать — приводи реальный код. А так все мои высказывания опираются на то что ты привел.

I>>>Вот фунцыя, находит все роуты в подграфе вершиной которого является root, снова модифицированый dfs.
G>>Кто такие роуты? В твоем коде черт ногу сломит. Рекурсия + mutable state читаемость снижают до нуля.
I>Там все очевидно, если ты знаешь что такое dfs. В данном случае mutable state не вносит никакой проблемы/
Я отлично знаю что такое dfs, но разобраться с твоим кодом за 5 минут не смог, а на больше меня не хватило.

I>И заметь — как дело дошло до реального примера, ты в очередной раз сдулся. На будущее — не проси у меня примеров кода.
Я же говорю — напиши по-русски что делает. Потому что я не понял какую задачу решает код. А пляски с анонимными рекурсивными функциями меня мало интересуют.

Ты кстати опять прячешь знания за терминологией. Ты уже промахнулся с визиторами, теперь повторяешь про bfs, но не говоришь зачем этот bfs нужен.

Здравствуйте, gandjustas, Вы писали:

G>>>Только непонятно нифига. А обобщенный комбинатор пишется и отлаживается ровно один раз.

I>>Я и вижу — ошибку в своем коде ты не смог пофиксить
G>Где там ошибка, ткни пальцем.

Я внятно объяснил и даже ткнул пальцем

Есть ошибка, которая вобщем то и у меня в наличии — HashSet нужен для завершения рекурсии.
Тебя, вероятно ввело в заблуждение слово Childs, правильнее назвать Connections.
Вот, нужно добавить:
Visitor<Vertex> visit = (v) => {if(hash.Contains(v)) return; hash.Add(v); visitList(v.Childs); };

Соответсвенно эту же корректировку нужно делать и в твоем случае, иначе обход никогда не завершится.

I>>Там все очевидно, если ты знаешь что такое dfs. В данном случае mutable state не вносит никакой проблемы/
G>Я отлично знаю что такое dfs, но разобраться с твоим кодом за 5 минут не смог, а на больше меня не хватило.

Я заметил

I>>И заметь — как дело дошло до реального примера, ты в очередной раз сдулся. На будущее — не проси у меня примеров кода.
G>Я же говорю — напиши по-русски что делает. Потому что я не понял какую задачу решает код. А пляски с анонимными рекурсивными функциями меня мало интересуют.

Ты и читать похоже разучился:
"Назначение функции — вычислить подграф c определенным порядком следования вертексов, для чего используется модифицированый dfs"

"Вот фунцыя, находит все роуты в подграфе вершиной которого является root, снова модифицированый dfs. Покажи мне Linq и Комбинаторы "

G>Ты кстати опять прячешь знания за терминологией. Ты уже промахнулся с визиторами, теперь повторяешь про bfs, но не говоришь зачем этот bfs нужен.

А ты прочесть попробуй. С визиторами я не промахнулся, кстати говоря.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Ikemefula, Вы писали:

I>>Чушь. Открываешь любую книгу и читаешь — операции над объектной структурой

НС>Под это определение подходят чуть болеечем все поведенческие паттерны

Чушь.

НС>Ну да цитату в студию. Лучше всего из банды, первоисточник все таки.

Там кривое изложение. Что мешает работать с помощью визитора над структурой состоящей из N иерархий ? Вероятно в твоем случае это идеология, потому что ты ГоФ понял буквально.

I>>. Общий корень может быть а может и не быть. А вот двойная диспетчеризация будет обязательно.

НС>С точностью до наоборот.

В некоторых источниках визитор вообще сводится к двойной диспетчеризации.

Двойная диспетчеризация не нужна в динамических языках и языках с PM. В них и визитор вообще не нужен.

I>> Но если ты прочтешь тобой же написано, то окажется, что общий корень вовсе необязательно.

НС>В общем случае — нет, в шарпе — обязателен (до C# 4 по крайней мере). Потому что для общего виртуального метода необходим общий корень.

Виртуальный метод необязателен Утиной типизации может быть достаточно, еще можно быть достаточно простой матрицы если методов и типов очень много.

I>>Процитируй, уважаемый Трепло, где же я такое сказал.

НС>Я не про тебя, неуважаемое Хамло.

Отвечаешь мне, а пишешь не мне

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Ночной Смотрящий, Вы писали:

I>>>Вообще говоря визитор это не только когда диспетчеризация по типам с общим корнем.

НС>>Вообще говоря только. По определению.

I>Чушь. Открываешь любую книгу и читаешь — операции над объектной структурой. Общий корень может быть а может и не быть. А вот двойная диспетчеризация будет обязательно.

Давай пойдем от обратного. Представим что нет ничего общего между различными типам A, B и надо выполнить обход структуры, которую они представляют.
Для общности представим что каждый из типов A и B имеет ссылки на объекты типов A и B.

Далее как будет выглядеть обход. Так как нет общего предка, то будет две точки входа: функции VisitA и VisitB. При обходе каждая из них будет вызывать isitA и VisitB при необходимости.

Ну вот и нету двойной диспетчеризации, даже одинарной нет. Если конечно воспользоваться статическим полиморфизмом, то вполне можно сделать статическую одинарную диспетчеризацию, но это совершенно необязательно.

Кстати для визитора в определении GOF двойная диспетчеризация — не цель, а средство. Цель — отвязать операции со структурой от самой структуры, чтобы операции можно было менять произвольно.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

G>>>>Только непонятно нифига. А обобщенный комбинатор пишется и отлаживается ровно один раз.

I>>>Я и вижу — ошибку в своем коде ты не смог пофиксить
G>>Где там ошибка, ткни пальцем.

I>Я внятно объяснил и даже ткнул пальцем

I>

I>Есть ошибка, которая вобщем то и у меня в наличии — HashSet нужен для завершения рекурсии.
I>Тебя, вероятно ввело в заблуждение слово Childs, правильнее назвать Connections.
I>Вот, нужно добавить:
I>Visitor<Vertex> visit = (v) => {if(hash.Contains(v)) return; hash.Add(v); visitList(v.Childs); };

I>Соответсвенно эту же корректировку нужно делать и в твоем случае, иначе обход никогда не завершится.

Нафига мне за твоими изменениями гоняться? Ты так можешь в каждом посте ченить придумывать и будешь делать вид что всегда прав.

I>>>И заметь — как дело дошло до реального примера, ты в очередной раз сдулся. На будущее — не проси у меня примеров кода.
G>>Я же говорю — напиши по-русски что делает. Потому что я не понял какую задачу решает код. А пляски с анонимными рекурсивными функциями меня мало интересуют.

I>Ты и читать похоже разучился:
I>"Назначение функции — вычислить подграф c определенным порядком следования вертексов, для чего используется модифицированый dfs"
"вычислить подграф c определенным порядком следования вертексов" вот это сформулируй в проверяемом виде. А то я тебе ченить напишу, а ты опять 30 раз условие поменяешь.

I>С визиторами я не промахнулся, кстати говоря.
Очень промахнулся. Ты даже не можешь толково объяснить где у тебя в коде визитор. Потому что под определение GOF он не подходит, а под те определения, которые ты придумываешь (кстати ссылку на источник хотелось бы видеть) подходит то, что даже отдаленно не является визитором.
Хотя если ты называешь визитором вообще любой обход любой нетривиальной структуры, то см выделенное выше.