Здравствуйте, IB, Вы писали:
V>>Пока это не превращается в полнейшую клинику, как в случае IB — я лишь лениво отмахиваюсь. V>>Подумаешь, рвануло анус у IB, подумаешь, я ответил пару раз в его же манере. V>>А я уверен, поймай того же IB в реальной жизни — так он сразу просто душка будет! IB>А я молодец! Как же тебя расплющило-то, большая часть сообщения опять про меня =)
Ты же так старался, бедный, почему бы не похвалить?
IB>И как выяснилось, ты еще и трус — напрямую ответить стремаешься, осталось по чужим топикам шарахаться.
Ага, рассуждал модератор, раз за разом провоцируя посетителя сайта.
Иди уже, охладись.
_>1. берём код Синклера из теста _>2. переименовываем его вариант функции select во что-нибудь другое, например в map2d _>3. меняем код запуска алгоритма с "from d in data select ... " на "map2d(data, d=>...)" _>4. убираем все упоминания о linq в проекте (т.е. даже import System.Linq не будет) _>5. проводим показанные Синклером тесты и убеждаемся что получили в точности тоже самое быстродействие при том же самом разделение задания алгоритма и кода его реализации
_>Т.е. на самом деле цель была достигнута без всякого Linq, а оно было пристёгнуто просто для видимости.
Здравствуйте, vdimas, Вы писали:
V>Опять советы удумал давать?
Ну что ты! Исключительно указываю направление =)
V>И продолжаю замечательно с другими коллегами.
Они просто люди вежливые, стесняются ответить как есть, вот ты и паразитируешь на их великодушии. )) И то уже практически со всеми разосрался )
V>Просто конкретно тебе мне ответить нечего.
Что, собственно, и требовалось доказать. ) Если из твоих постов убрать все бахвальство, туманные намеки на не пойми что, прямое хамство, домыслы о том что якобы имели ввиду оппоненты и какую-то крайне не здоровую мнительность, то сути останется совсем мало ((
V>Твои желания пофлеймить, не совпадают с твоими возможностями.
Твоя реакция наглядно доказывает обратное, а с этим твоим утверждением выглядит еще смешнее
Здравствуйте, vdimas, Вы писали:
V>Ага, рассуждал модератор, раз за разом провоцируя посетителя сайта.
Так ты не ведись, если модераторов боишься =))
Но не переживай, в этом форуме я не модератор, и никогда таковым не был )
Тут linq не для решения задачи. А для того, чтобы это решение использовать в прикладном коде стандартным образом. В данном случае linq — просто универсальный контракт между разработчиком библиотеки и приложения.
Другое дело, что для задачи такого типа, такой универсальный контракт возможно и не очень нужен — мощь линка в сложных выражениях, а здесь, если не нужно цепочки разных алгоритмов с хитрыми условиями на изображение накладывать, эта красота вряд ли пригодится (но и не помешает).
Но тут надо понимать историю вопроса, alex_public довольно тонкий манипулятор и это один из его типичных приемов =)
Следите за руками:
a_p> С линком "вот так" сделать нельзя, будет не удобно и тормозно, там везде IEnumerable, а в конце все равно будут банальные циклы. s> Хмм.. Ну давай попробуем, "вот", "вот" и "вот" — получилось в два раза быстрее, чем в лоб циклами. a_p> Нее, ну зачем тут линк? Тут можно просто функцию такую сделать.
То есть, сначала сам попросил выразить эту задачу через линк, а потом спрашивает, зачем это через линк-то делали...
Здравствуйте, IB, Вы писали:
V>>И продолжаю замечательно с другими коллегами. IB>Они просто люди вежливые, стесняются ответить как есть
Отвечай по делу и не надо будет ломать голову над ответами "как есть".
Не можешь? — не отвечай ничего.
IB>вот ты и паразитируешь на их великодушии.
Опять вытащил на свет божий своё гавнецо.
V>>Просто конкретно тебе мне ответить нечего. IB>Что, собственно, и требовалось доказать.
Этого не требовалось доказывать, тебе об этом сообщили сразу же: "трепешься не по делу".
IB>Если из твоих постов убрать все бахвальство, туманные намеки на не пойми что, прямое хамство, домыслы о том что якобы имели ввиду оппоненты и какую-то крайне не здоровую мнительность, то сути останется совсем мало ((
Ну так убери лишнее, оставь суть, тогда и посмотрим, чего стоят твои спекуляции.
Но ты ж не справился, поэтому — свободен.
V>>Твои желания пофлеймить, не совпадают с твоими возможностями. IB>Твоя реакция наглядно доказывает обратное
Разве только моя?
Я наблюдаю с тобой одно и то же — пофлеймить в заданном тобой стиле у тебя не вышло еще ни разу.
Вместо следования заданному тобой "ключу" почему-то сходу нарываешься на ответы в стиле: "да вы просто какой-то дурак, батенька!".
С поправками на необходимое "замыливание", понятно, но в сухом остатке именно так.
Я бы задумался.
a_p>> Нее, ну зачем тут линк? Тут можно просто функцию такую сделать. IB>То есть, сначала сам попросил выразить эту задачу через линк, а потом спрашивает, зачем это через линк-то делали...
Он попросил это выразить через линк понятно зачем — чтобы "спорщики" сами убедились в его тормознутости.
А затем спросил, зачем приписали то, что сделали (а написано было, помимо решения целевой задачи, примерно в 300 раз больше кода) св-вам именно линка?
Уход от ответа на этот вопрос — вот где самая манипуляция в этом топике.
Ну и я тут обратил внимание, что в показанном виде под линк невозможно протащить прикладной контракт, не вернувшись обратно к первоначальным его тормозам.
Итого, всё вместе сходу превращается в тыкву.
В этом месте у тебя пукан-то и порвало, судя по хронологии произошедшего. ))
Здравствуйте, vdimas, Вы писали:
V>Отвечай по делу и не надо будет ломать голову над ответами "как есть".
Так я именно так и отвечаю, просто у тебя дело такое ))
V>Опять вытащил на свет божий своё гавнецо.
Ты о чем? Я исключительно твое на свет божий вытаскиваю. )
V>>>Просто конкретно тебе мне ответить нечего. IB>>Что, собственно, и требовалось доказать. V>Этого не требовалось доказывать,
Если и доказывать не требовалось, зачем ты вообще пишешь? Сам признал — сказать нечего, вот и молчи ))
V>тебе об этом сообщили сразу же: "трепешься не по делу".
Я то исключительно по делу, но речь не обо мне. )
V>Но ты ж не справился, поэтому — свободен.
С чем? Ты прекрсно ведешься, не вижу смысла останавливаться ))
V>Разве только моя?
Нет, не только, оценки сообщений тоже довольно красноречивы )
V>Я наблюдаю с тобой одно и то же — пофлеймить в заданном тобой стиле у тебя не вышло еще ни разу.
Твоя наблюдательность явно оставляет желать лучшего. )) Но то что у тебя с этим проблемы было понятно еще когда ты скрытые смыслы в чужих сообщениях искал.
видно же, что ты кому-то в своей голове отвечаешь, а не на то что было написано. )
V>Я бы задумался.
Так задумайся! Последуй уже наконец собственному совету ))
Здравствуйте, vdimas, Вы писали:
V>Попридержи свои советы при себе. V>Как-нить сам разберусь, что мне делать. Будь мужиком, начни с себя! Не давай мне советов, кому что советовать! =)
Да и разобраться у тебя что-то не очень получается ))
Здравствуйте, vdimas, Вы писали:
V>Опять брехня, никто манипуляции не разводил.
Я их наглядно продемонстрировал. )
V>Очевидно, Алекс имел ввиду имеющуюся функциональность линка и имеющиеся способы описания контракта к линку.
Вот с этого места можно по подробнее. Что такое "функциональность линка" и какие способы описания контракта у нас имеются?
Ну просто, чтобы разговор был предметным и не пришлось потом опять выслушивать "ой, я не это имел ввиду" (с)
V>1. С неустранимыми ошибками:
Пока что неустранимая ошибка только у тебя в голове.
V>2. "В лоб циклами" (С) можно обращаться к двумерному массиву примерно вдвое быстрее: V>http://www.rsdn.org/forum/dotnet/7187427.1 V>А если протягивать в цикле курсоры, то более чем втрое быстрее: V>http://www.rsdn.org/forum/dotnet/7188188.1
Мало того, что это не так, так это еще и не имеет отношения к продемонстрированному подходу. Даже если бы тебе удалось придумать способ, который в десять раз быстрее чем то, что предложил Антон, то это все равно бы доказало его позицию.
Потому что, (вот сейчас, еще раз, внимательно) линк не про реализацию, а про то, как отделить реализацию от ее использования.
V>Он попросил это выразить через линк понятно зачем — чтобы "спорщики" сами убедились в его тормознутости.
Именно. Но почему-то получилось наоборот, утверждатели в тормознутости вынуждены были придумывать, почему это не линк.
V>А затем спросил, зачем приписали то, что сделали (а написано было, помимо решения целевой задачи, примерно в 300 раз больше кода) св-вам именно линка?
А теперь вернемся к началу. Что такое "свойства именно линка"?
Мы уже победили, просто это еще не так заметно...
Re[40]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, IB, Вы писали:
V>>>>Просто конкретно тебе мне ответить нечего. IB>>>Что, собственно, и требовалось доказать. V>>Этого не требовалось доказывать, IB>Если и доказывать не требовалось, зачем ты вообще пишешь? Сам признал — сказать нечего, вот и молчи ))
Оу, смотрю, запутался в собственных показаниях напрочь. ))
Судя по твоей писанине, тебе нравится обмениваться "любезностями" с колегами.
Показал себя еще тем любителем словесного БДСМ.
Дык, спасибо должен говорить, что коллеги тебя поддерживают!
Вместо этого ведешь себя как неблагодарная сам знаешь кто... ))
Здравствуйте, IB, Вы писали:
V>>Попридержи свои советы при себе. V>>Как-нить сам разберусь, что мне делать. IB> Будь мужиком, начни с себя! Не давай мне советов, кому что советовать! =)
Инфа для чебурашек из далёких стран о правилах нашего мира:
— когда по рылу в ответ, то не считается.
IB>Да и разобраться у тебя что-то не очень получается ))
Здравствуйте, IB, Вы писали:
V>>Опять брехня, никто манипуляции не разводил. IB>Я их наглядно продемонстрировал. )
Ты показал умение написать слово "манипуляция" без грамматических ошибок, разве что.
Манипуляция — это когда сознательно недоговаривают, врут, играют одновременно на неполной информации и на эмоциях.
Ничего из этого Алекс не делал, разумеется, т.е. ты на него клевещешь.
Зато вы с Синклером только этим и заняты.
V>>Очевидно, Алекс имел ввиду имеющуюся функциональность линка и имеющиеся способы описания контракта к линку. IB>Что такое "функциональность линка"
Это имеющиеся Enumerable и Queryable классы, плюс правила маппинга синтаксиса языка выражений на обычные методы или на методы расширений.
IB>и какие способы описания контракта у нас имеются?
Для рассматриваемого случая select всего 2 по 2:
— функциональная лямбда по элементу
— функциональная лямбда по элементу+индексу
— дерево выражений лямбды по элементу
— дерево выражений лямбды по элементу+индексу
Это всё.
Для случая Синклера и вовсе только первый вариант.
Т.е., прикладной контракт при вызове select протягивать банально некуда.
Этот контракт можно попытаться завернуть в саму "лямбду", т.е. манипулировать контрактом при каждом обращении к элементу.
Получается возврат на круги своя — ноль оптимизаций.
Берем другую технику — накручиваем контракт поверх самих "коллекций", мол, тогда функциональность "контракта" работает однократно.
Здесь спотыкаемся о необходимость стирания типов.
Т.е., если типы не стирать, то комбинаторный взрыв из более-менее полной библиотеки оперируемых контрактов быстро улетит в бесконечность.
А если типы стирать, то всегда будет лишний боксинг.
Собсно, подробно на всё это я уже отвечал, но ты мне почему-то отписывался совсем по другому поводу.
Ну и, технике Linq уже 13 лет, хорошо же видно, какие задачи на нём решают, а какие даже не пытаются.
Или пытались, что скорее всего, но по итогам на свет божий решили не выкатывать. ))
Т.е. Алекс, не обладая глубокими знаниями конкретно по дотнету, но обладая достаточным инженерным опытом, вполне мог сделать "реверс инжиниринг" такого положения дел, бо законы больших чисел — они ведь неумолимы.
Т.е. если ВООБЩЕ ВСЯ отрасль в течении аж 13-ти лет даже не пытается так делать, значит на это есть серьёзные причины, не?
V>>1. С неустранимыми ошибками: IB>Пока что неустранимая ошибка только у тебя в голове.
Во-во, опять гавнецо в ответ на сугубо технический аргумент.
Слился.
IB>так это еще и не имеет отношения к продемонстрированному подходу.
Наоборот, я сначала посмотрел подход, потом попытался наваять что-то типа такого же, только без IL-генератора и без linq.
Там внутри просто unsafe-цикл.
4-й по счёту мой "индексер", даже который не протягивает курсоры, а просто является относительно безопасной обёрткой, показывает почти вдвое ускорение операции доступа к двумерному массиву.
IB>Даже если бы тебе удалось придумать способ, который в десять раз быстрее чем то, что предложил Антон, то это все равно бы доказало его позицию.
При условии, если бы ему удалось придумать способ безопасного обхода массива.
Ему это пока что не удалось:
int _x;
public int x => (_x++)/100;
...
from d in data select (d[-x, 0] + d[x, 0] + ...
Причём, здесь просто выжимка/суть, а в реальном коде такая ситуация может возникнуть через какое-нить прикладное сочетание вызовов.
Я несколько раз говорил это словами (тут же, по-идее, собрались люди, понимающие дотнете, не?)
Пришлось даже написать в чём проблема, и внятной реакции на это до сих пор не вижу.
IB>Потому что, (вот сейчас, еще раз, внимательно) линк не про реализацию, а про то, как отделить реализацию от ее использования.
Да без проблем, если бы такое разделение не нарушало бы прикладной контракт.
V>>Он попросил это выразить через линк понятно зачем — чтобы "спорщики" сами убедились в его тормознутости. IB>Именно. Но почему-то получилось наоборот, утверждатели в тормознутости вынуждены были придумывать, почему это не линк.
Мои хелперы показали, почему это не линк. ))
V>>А затем спросил, зачем приписали то, что сделали (а написано было, помимо решения целевой задачи, примерно в 300 раз больше кода) св-вам именно линка? IB>А теперь вернемся к началу. Что такое "свойства именно линка"?
Давай вернёмся.
Это способ маппинга выражений языка запросов на методы объектов или на методы-расширения.
Моё мнение тут простое — сам этот способ маппинга НЕ расширяемый, поэтому прикладной контракт "подавать" некуда.
Здравствуйте, vdimas, Вы писали:
V>Ты показал умение написать слово "манипуляция" без грамматических ошибок, разве что. V>Манипуляция — это когда сознательно недоговаривают, врут, играют одновременно на неполной информации и на эмоциях. V>Ничего из этого Алекс не делал, разумеется, т.е. ты на него клевещешь.
На счет сознательно — это необязательно. И ответственности не эти не снимает. Скажем, типичный пример — это c4 фильтр, он сам предложил задачу и сам же забраковал решение. Может он ожидал, что Синклер сделает это через IQueryable. Но о своих ожиданиях он умолчал, уточнения он как правило игнорирует или начинает забалтывать, кривляться-стебаться, делать вид что непонимает и тд.
Вот, скажем, два года назад была речь про предкомпиляцию запросов в БД:
IT: "Предкомриляция запроса внутри БД делается самой БД без каких-либо телодвижений с клиента. Если ты о методе Prepare из ADO.NET, то он делается на открытом соединении и держать его открытым между вызовами не самая лучшая идея."
И вот как это прочёл наш герой:
alex_public: "В данной дискуссии выяснилось что данные ORM почему-то не умеют и предкомпилированные в СУБД запросы"
Теперь прошло два года, и смотрим, чего поменялось. Речь про CTE:
IB: "есть ограничение языка, которое не позволяет записать рекурсивную лямбду. Есть обход этого ограничения но он грязный. Лямбды — это часть линка, следовательно, ограничения на лямбды, равно как и их обход, относятся в том числе и к линку. Никаких дополнительных ограничений у линка нет. Следовательно и проблема та же самая, и решение то же, и это не эксперимент, и это ограничение языка, а не непосредственно линка. "
Здесь речь про ограничение языка и характеристику обходного решение — "грязное". Здесь же явное утверждение, что linq ни при чем.
Теперь слово alex_public:
alex_public: "Ну так если это очевидное "грязное" решение по написанию рекурсивных лямбд так же элементарно подходит и для linq, то тогда почему поддержка CTE появилось только на днях и только в одной (далекое не самой популярной) Linq библиотеке"
Вот он или не понял, или продолжает кривляться. Но тут же сам и пишет, что CTE появилось только в одной библиотеке и задаётся вопросом "почему" ? Ему только что дали на это ответ, но он все еще почемучкает. И далее:
alex_public: "Т.е. поддержка CTE в linq2db сделана грязно и неудобно, я правильно тебя понял? )"
То ли товарищ вообще не читает, ни что сам пишет, ни что ему пишут, то ли не понимает, то ли специально кривляется и валяет дурака. Ну, как вариант, у него память ровно на текущее сообщение. Но это вобщем тоже показатель "адекватности"
Собственно, это типичная картина того, как идет общение с alex_public.
Здравствуйте, Ikemefula, Вы писали:
I>Скажем, типичный пример — это c4 фильтр, он сам предложил задачу и сам же забраковал решение.
Учитель в школе тебе сам же предлагает задачу, сам же двойки ставит.
Все учителя злостные манипуляторы, по-твоему.
I>Может он ожидал, что Синклер сделает это через IQueryable.
Гадания на кофейной гуще.
Почти всегда переводят обсуждение в срач.
I>Но о своих ожиданиях он умолчал, уточнения он как правило игнорирует или начинает забалтывать, кривляться-стебаться, делать вид что непонимает и тд.
Он понимает достаточно, чтобы предположить — задёшево относительную адресацию в линке не сделаешь.
Не заточен потому что линк на это.
I>Вот, скажем, два года назад была речь про предкомпиляцию запросов в БД:
I>IT: "Предкомриляция запроса внутри БД делается самой БД без каких-либо телодвижений с клиента. Если ты о методе Prepare из ADO.NET, то он делается на открытом соединении и держать его открытым между вызовами не самая лучшая идея."
I>И вот как это прочёл наш герой: I>alex_public: "В данной дискуссии выяснилось что данные ORM почему-то не умеют и предкомпилированные в СУБД запросы"
Выглядит так, что ты путаешь предкомпилённый запрос на стороне базы и предкомпиляённый запрос драйвера OleDbCommand.Prepare().
Это разные вещи.
Первый просто кеширует запрос (или не кеширует, или кеширует, но потом запрос из кеша улетает), второй на уровне драйвера делает следующее:
(1) производит валидацию типов аргументов локально;
(2) производит валидацию типов аргументов удалённо;
(3) производит валидацию/компиляцию самого запроса удалённо;
(4) сопоставляет клиентский запрос с соотв. предкомпиллированной версией на стороне сервака.
При последующих вызовах (в серии их) операции 1, 2, 3 и 4 уже не производятся.
Пока жив объект OleDbCommand, закешированная версия запроса из кеша сервера вытеснена не будет.
Если же обсуждаемые ORM заточены на однократные вызовы запросов к БД, то им смысла в локальном prepare нет, разумеется.
I>Теперь прошло два года, и смотрим, чего поменялось. Речь про CTE:
I>IB: "есть ограничение языка, которое не позволяет записать рекурсивную лямбду. Есть обход этого ограничения но он грязный. Лямбды — это часть линка, следовательно, ограничения на лямбды, равно как и их обход, относятся в том числе и к линку. Никаких дополнительных ограничений у линка нет. Следовательно и проблема та же самая, и решение то же, и это не эксперимент, и это ограничение языка, а не непосредственно линка. " I>Здесь речь про ограничение языка и характеристику обходного решение — "грязное". Здесь же явное утверждение, что linq ни при чем.
Если бы ты был сосредоточен не на словах, не на фигне навроде "а вот он такое-то говорил, бе-бе-бе", а на сути происходящего, ты бы обнаружил слудующее:
— ср-ва для обхода ограничения на рекурсию лямбд в языке есть — это известный Y-комбинатор.
— язык запросов linq вполне мог бы реализовать его прозрачно для программиста... но! даже этого не требуется!
— ввиду того, что лямбды унутре выполнены как обычные объекты-замыкания, Y-комбинатор не нужен, достаточно обычной рекурсии в методе такого объекта.
Шах и мат. ))
Всё это напомнило мне другой аналогичныйслучай — linq-rewrite, с ним носятся как с писанной торбой, мол, ОГО ФИЧА!!!
А что мешало реализовать её прямо в компиляторе?
I>Вот он или не понял, или продолжает кривляться. Но тут же сам и пишет, что CTE появилось только в одной библиотеке и задаётся вопросом "почему" ? Ему только что дали на это ответ
Как я только показал — никакой "ответ" не дали.
За такой "ответ" в школе двойки ставят сходу.
I>То ли товарищ вообще не читает, ни что сам пишет, ни что ему пишут, то ли не понимает, то ли специально кривляется и валяет дурака. Ну, как вариант, у него память ровно на текущее сообщение. Но это вобщем тоже показатель "адекватности"
Э, не, адекватность — это обратная сторона объективности.
Но пока что необъективными выглядят ваши аргументы.
Вам достаточно выйти из вашей странной позы и признать, да, вот здесь, здесь и здесь малость недоработано.
И вместо того, чтобы компосировать моск более объктивным "внешним наблюдателям", типа Алекса, лучше бы сходил в гитхаб на CoreFX и там озвучил бы свои пожелания одновременно с вполне конкретными техническими причинами (как я дал выше) почему твои пожелания вполне имеют право на жизнь.
Это будет адекватно.
Происходящее здесь замыливание "неудобных" моментов — нет.
Со стороны смотрится как тихий дурдом, как параллельная вселенная в сравнении с "обычной" инженерией.
Здравствуйте, vdimas, Вы писали:
I>>Скажем, типичный пример — это c4 фильтр, он сам предложил задачу и сам же забраковал решение.
V>Учитель в школе тебе сам же предлагает задачу, сам же двойки ставит. V>Все учителя злостные манипуляторы, по-твоему.
Я не понимаю, чего ты хотел сказать.
V>Он понимает достаточно, чтобы предположить — задёшево относительную адресацию в линке не сделаешь.
Это твои домысла, чего он понимает, а чего нет ?
I>>Вот, скажем, два года назад была речь про предкомпиляцию запросов в БД:
I>>IT: "Предкомриляция запроса внутри БД делается самой БД без каких-либо телодвижений с клиента. Если ты о методе Prepare из ADO.NET, то он делается на открытом соединении и держать его открытым между вызовами не самая лучшая идея."
I>>И вот как это прочёл наш герой: I>>alex_public: "В данной дискуссии выяснилось что данные ORM почему-то не умеют и предкомпилированные в СУБД запросы"
V>Выглядит так, что ты путаешь предкомпилённый запрос на стороне базы и предкомпиляённый запрос драйвера OleDbCommand.Prepare(). V>Это разные вещи.
Ты упорный нечитатель. Одно высказывание от ИТ, второе — как его понял alex_public.
V>При последующих вызовах (в серии их) операции 1, 2, 3 и 4 уже не производятся. V>Пока жив объект OleDbCommand, закешированная версия запроса из кеша сервера вытеснена не будет. V>Если же обсуждаемые ORM заточены на однократные вызовы запросов к БД, то им смысла в локальном prepare нет, разумеется.
Вот это расскажи не мне, а alex_public, а то он уверен, что здесь linq виноват.
V>- ср-ва для обхода ограничения на рекурсию лямбд в языке есть — это известный Y-комбинатор.
Вот это и есть кривое решение, которое не нужно тащить в АПИ. Храбрости такое сделать хватило только у linq2db, остальные наверное по сей день в ужасе
V>- ввиду того, что лямбды унутре выполнены как обычные объекты-замыкания, Y-комбинатор не нужен, достаточно обычной рекурсии в методе такого объекта. V>Шах и мат. ))
Покажи код, как без Y-комбинатора писать рекурсию в лямда-выражениях.
V>Как я только показал — никакой "ответ" не дали.
Ты пока ничего не показал. Какой то месяц назад или два, ты тужился над Y-комбинатором, а сейчас утверждаешь, что он не нужен Ради чего ты тужился тогда ? "Я тоже так могу" ?
Здравствуйте, Ikemefula, Вы писали:
V>>Он понимает достаточно, чтобы предположить — задёшево относительную адресацию в линке не сделаешь. I>Это твои домысла, чего он понимает, а чего нет ?
Я сужу по его словам прямо.
Ты же пытаешься приписать доп. контекст, смешивая разные ветки обсуждений — где обсуждались запросы в базу и запросы над коллекциями.
I>>>И вот как это прочёл наш герой: I>>>alex_public: "В данной дискуссии выяснилось что данные ORM почему-то не умеют и предкомпилированные в СУБД запросы" V>>Выглядит так, что ты путаешь предкомпилённый запрос на стороне базы и предкомпиляённый запрос драйвера OleDbCommand.Prepare(). V>>Это разные вещи. I>Ты упорный нечитатель. Одно высказывание от ИТ, второе — как его понял alex_public.
Даже не берясь судить, что Алекс имел ввиду, его утверждение является истинной.
V>>При последующих вызовах (в серии их) операции 1, 2, 3 и 4 уже не производятся. V>>Пока жив объект OleDbCommand, закешированная версия запроса из кеша сервера вытеснена не будет. V>>Если же обсуждаемые ORM заточены на однократные вызовы запросов к БД, то им смысла в локальном prepare нет, разумеется. I>Вот это расскажи не мне, а alex_public, а то он уверен, что здесь linq виноват.
По его словам не linq, а конкретные ORM, с чем я пока согласен.
Т.е. с "вашей" стороны спор должен был переместиться в другую область — а насколько востребован клиентский Prepare() в тех областях, для которых предназначены упомянутые ORM?
V>>- ср-ва для обхода ограничения на рекурсию лямбд в языке есть — это известный Y-комбинатор. I>Вот это и есть кривое решение, которое не нужно тащить в АПИ.
Не в АПИ, а в реализацию компилятора C#.
Язык запросов САМ генерит лямбды из тела запросов, помнишь еще?
V>>- ввиду того, что лямбды унутре выполнены как обычные объекты-замыкания, Y-комбинатор не нужен, достаточно обычной рекурсии в методе такого объекта. V>>Шах и мат. )) I>Покажи код, как без Y-комбинатора писать рекурсию в лямда-выражениях.
Я правильно понял твой вопрос, что ты хочешь посмотреть на некий гипотетический синтаксис выражений linq и соотв. сгенерённый компилятором объект-замыкание?
Я тут могу даже поиграть в большее — предложи синтаксис, а я попробую расписать сгенерённый объект лямбды.
I>Какой то месяц назад или два, ты тужился над Y-комбинатором, а сейчас утверждаешь, что он не нужен.
А что ты не понял из этого:
- язык запросов linq вполне мог бы реализовать его прозрачно для программиста...
— ... достаточно обычной рекурсии в методе такого объекта (атогенерённого по исходнику лямбды).
I>Ради чего ты тужился тогда ? "Я тоже так могу" ?
Там чёрным по-белому написано ради чего — посмотреть, насколько это практично.
Из-за двух лишних уровней косвенности описания, делающих невозможным автовывод типа делегата — получается абсолютно не практично.
Но у компилятора такой проблемы нет — типы ему известны, т.е. он может сгенерить нужный код.
Дело за реализацией. ))
Мы уже победили, просто это еще не так заметно...
