Здравствуйте, _FRED_, Вы писали:
_FR><skipped>
_FR>3. Мне гораздо несимпатичнее отладка такого кода: _FR>
_FR>Some1();
_FR>for(var x in yy) {
_FR> // … сотня-другая итераций
_FR>}//fir
_FR>Some2();
_FR>
_FR>когда меня не интересуют внутренности работы цикла (требуется от Some1 перейти к Some2). Отладчик не умеет "перепрагивать" через цикл и приходится ставить специальный breakpoint к Some2(); и перепрыгивать цикл самому.
Ctrl+F10 спасут отца русской демократии И без всяких бряков
Здравствуйте, koandrew, Вы писали:
_FR>>когда меня не интересуют внутренности работы цикла (требуется от Some1 перейти к Some2). Отладчик не умеет "перепрагивать" через цикл и приходится ставить специальный breakpoint к Some2(); и перепрыгивать цикл самому.
K>Ctrl+F10 спасут отца русской демократии И без всяких бряков
Что это за команда и как она поможет?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>При чём здесь "дизайн языка", когда речь о библиотечном методе?
А библиотечный метод как-то в отрыве от языка существует?
_FR>Слова были о дизайне библиотеки, о том, что данные метод плохо бы смотрелся среди других методов.
Этот метот в принципе плохо смотрелся бы, если нет желания писать полноценную библиотеку методов с семантикой изменения состояния. И этот метод всегда библиотечный, даже если библиотека — это один класс из одного метода, он по сути своей хелперный.
_FR>Я вижу слова "Я философски против предоставления такого метода по двум причинам."
Какая разница предоставления кем? Я не вижу аргументов за наличие такого метода в своих библиотеках и, более того, я вижу вполне внятные аргументы против.
_FR>Я не вижу ответа в тексте блога на вопрос "почему плохо в своём коде иметь такой метод".
Аргументов в этой заметке достаточно и для моего кода.
_FR>1. никто не заставляет пользоваться замыканиями, так что данное обоснование кажется надуманным.
Никто не заставляет вообще пользоваться этим методом. Зачем мне метод с побочными эффектами, если можно обойтись без них, стандартными средствами?
_FR>2. Это вопрос самый спорный.
Наоборот, самый бесспорный =) plain foreach — чище, очевиднее и понятнее любого метода с Action<T> в качестве аргумента, я не понимаю, какие тут вообще могут быть сомнения..
_FR>когда меня не интересуют внутренности работы цикла (требуется от Some1 перейти к Some2). Отладчик не умеет "перепрагивать" через цикл и приходится ставить специальный breakpoint к Some2(); _FR>и перепрыгивать цикл самому.
Поставить дополнительный breakpoint — это один клик мышкой, при том, что весь код перед глазами. А вот когда проблемы на какой-то из итераций — все гораздо веселее.
_FR>Использование одной строчки там, где в другом случае нужно много больше.
Не много, а ровно на одну — я уже писал, что этот аргумент вообще несерьезный.
_FR>Для стандартной библиотеки — да.
Для нестандартной тоже. Другие аргументы, кроме числа строк кода есть?
_FR>Мне кажется, что этих эффектом можно добиться и без ForEach.
И с каких пор возможность прострелить себе ногу, стала аргументом в пользу того, чтобы еще и давать себе повеситься?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Знаешь, "по-русски" я бы тебе давно уже объяснил, что я думаю о подобных гайдлайнах — да боюсь забанят.
С тобой-то давно ясно, что закон тебе не писан.. Ну да кто ж тебе доктор?
ВВ>А в данном случае непонятно — откуда возникает требование этого функционального стиля?
Родной, это не требование, это дизайн такой. Расширяющие методы работы с коллекциями, не меняют состояния коллекций.
Если хочешь изменить — есть другие средства. Меняя такое положение дел, ты нарушаешь привычную логику, чем затрудняешь понимание твоего кода.
ВВ>Если передо мной стоят задачи модификации
Ты не знаешь как их решить, без ForEach?
ВВ>или, не дай бог, появляются методы имеющие сохраняемое состояние — то причем здесь вообще функциональный стиль?
А почему ты здесь функциональный стиль вспомнил?
У тебя очевидный пробел в логике, смотри: Дизайн операторов на последовательностях != вообще вся работа с последовательностями. Если тебе нужно последовательности менять, то в чем проблема использовать стандартный подход, вместо того, чтобы пытаться применить инструмент не по делу?
Никто не запрещает менять последовательность — не рекомендуют это делать с помощю средств для этого не предназначеных, что вообщем логично.
ВВ> И почему это должно быть функционально, если в действительности это не функционально ни на йоту?
Что именно не функционально?
ВВ>Это мы только ForEach<> касаемся, а можно еще и рассмотреть всякие Aggregate<> — там ведь вообще ужас с этой точки зрения.
Ты точно понял, что написал?
ВВ>String.Replace — очень схожая задача с обсуждаемой здесь.
Нет, не схожая, нужно объяснять почему?
ВВ> И совершенно нефункционально.
Функционально на 100%, нужно объяснять почему?
ВВ>Дизайну Шарпа противоречит императивный стиль?
Руководствуясь какой логикой ты такой вывод сделал?
ВВ>Функциональному дизайну Линка, который здесь вообще не причем, противоречит императивный стиль?
Ну и зачем ты его вспомнил, если он непричем?
ВВ>То же самое можно сказать и про Where по сравнению с foreach.
Нельзя, нужно объяснять почему?
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, koandrew, Вы писали:
_FR>>>Что это за команда и как она поможет?
K>>Debug.RunToCursor
_FR>Во ё-моё, а мне казалось что эта команда заставляет отладчик перепрыгнуть к курсору
Неа... Debug.RunToCursor —
...для запуска отладчика и выполнения кода до позиции курсора
Да и вообще, зацените весь список. Может еще чего вскроется...
Здравствуйте, IB, Вы писали:
ВВ>>Знаешь, "по-русски" я бы тебе давно уже объяснил, что я думаю о подобных гайдлайнах — да боюсь забанят. IB>С тобой-то давно ясно, что закон тебе не писан.. Ну да кто ж тебе доктор?
Мне с тобой тоже все ясно. Рад, что хотя бы здесь у нас полный консенсус.
ВВ>>А в данном случае непонятно — откуда возникает требование этого функционального стиля? IB>Родной, это не требование, это дизайн такой. Расширяющие методы работы с коллекциями, не меняют состояния коллекций.
Я где-то меняю состояние коллекции?
ВВ>>или, не дай бог, появляются методы имеющие сохраняемое состояние — то причем здесь вообще функциональный стиль? IB>А почему ты здесь функциональный стиль вспомнил? IB>У тебя очевидный пробел в логике, смотри: Дизайн операторов на последовательностях != вообще вся работа с последовательностями. Если тебе нужно последовательности менять, то в чем проблема использовать стандартный подход, вместо того, чтобы пытаться применить инструмент не по делу?
Тебе видимо разжевать нужно?
ОК. Я инструмент не по делу не применяю, свой инструмент можешь оставить при себе, я использую экстешин ForEach, который:
а) не несет в себе ничего функционального
б) не имеет никакого отношения к Линку
Так яснее?
ВВ>>Это мы только ForEach<> касаемся, а можно еще и рассмотреть всякие Aggregate<> — там ведь вообще ужас с этой точки зрения. IB>Ты точно понял, что написал?
А ты точно прочитал? Если с первого раза не получилось, попробуй повторно.
ВВ>>String.Replace — очень схожая задача с обсуждаемой здесь. IB>Нет, не схожая, нужно объяснять почему? ВВ>>То же самое можно сказать и про Where по сравнению с foreach. IB>Нельзя, нужно объяснять почему?
Объясни этому кому-нибудь другому. На сегодня я от тебя уже бреда наслушался.
Здравствуйте, IB, Вы писали:
_FR>>При чём здесь "дизайн языка", когда речь о библиотечном методе? IB>А библиотечный метод как-то в отрыве от языка существует?
Это не значит, что задачи дизайна языка можно сравнивать с задачами дизайна библиотеки. Здесь речь о дизайне библиотеки.
_FR>>Я не вижу ответа в тексте блога на вопрос "почему плохо в своём коде иметь такой метод". IB>Аргументов в этой заметке достаточно и для моего кода.
Всё, что из этого видно — то, что ты или веришь каким-то шестым чувством автору блога, или что вы с автором чего-то такое понимаете, что вам не удаётся онести до простых смертных (посмотри сколько там коментов написали такие же непонявшие). Так вот ни одна из этих причин не является обоснованной для "такого вот" давления на тех, "кто в танке". До тех пор, пока аргументы не будут ясны и понятны всем. Хорошо?
_FR>>1. никто не заставляет пользоваться замыканиями, так что данное обоснование кажется надуманным. IB>Никто не заставляет вообще пользоваться этим методом. Зачем мне метод с побочными эффектами, если можно обойтись без них, стандартными средствами?
Я уже сказал — просто продлить жизнь клавиатуре.
_FR>>2. Это вопрос самый спорный. IB>Наоборот, самый бесспорный =) plain foreach — чище, очевиднее и понятнее любого метода с Action<T> в качестве аргумента, я не понимаю, какие тут вообще могут быть сомнения..
хелпер, следуя твоей логике, не нужен? Ибо использование using в таком сценарии так же можно воспринять как неочевидность. Давайте захломлять код try\finnaly — добавляют ли они по-твоему "чистоты"? И если "нет", то почему foreach добавляет?
_FR>>Использование одной строчки там, где в другом случае нужно много больше. IB>Не много, а ровно на одну — я уже писал, что этот аргумент вообще несерьезный.
Перечитал твои посты в этой ветке — не нашёл. Ткни пожалуйста.
_FR>>Для стандартной библиотеки — да. IB>Для нестандартной тоже. Другие аргументы, кроме числа строк кода есть?
Нет.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Здесь речь о дизайне библиотеки.
Ну вот и не надо писать такие библиотечные методы.
_FR>Всё, что из этого видно — то, что ты или веришь каким-то шестым чувством автору блога, или что вы с автором чего-то такое понимаете, что вам не удаётся онести до простых смертных
Либо эти простые смертные настрлько любят свой ForEach, до которого додумались, что никакие рациональные аргументы их не интересуют.
_FR> Так вот ни одна из этих причин не является обоснованной для "такого вот" давления на тех, "кто в танке". До тех пор, пока аргументы не будут ясны и понятны всем. Хорошо?
На тех кто в танке — никто не давит. Я высказал свое мнение и свое отношение к этому вопросу, хорошо? А лечить тех кто в танке у меня нет ни малейшего желания.
_FR>Я уже сказал — просто продлить жизнь клавиатуре.
На аргумент не тянет, так как, например, по нашим стандартам, даже по числу нажатий на Enter оба варианта не отличаются.
_FR>Отлично. Тогда и показанный здесь
хелпер, следуя твоей логике, не нужен?
Какой хелпер?
_FR>Перечитал твои посты в этой ветке — не нашёл. Ткни пожалуйста.
В очередном ответе Васе Воронкову.
IB>>Другие аргументы, кроме числа строк кода есть? _FR>Нет.
Ну, вот собственно и все.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я где-то меняю состояние коллекции?
Конечно. Ты же тут начал разоряться про изменения. =)
ВВ>Тебе видимо разжевать нужно?
Васенька, родной, для начала лучше сам постарайся понять о чем ты, хотя бы для себя, так правда будет лучше.
ВВ>ОК. Я инструмент не по делу не применяю,
Ты именно это и делаешь
ВВ>, я использую экстешин ForEach, который: ВВ>а) не несет в себе ничего функционального ВВ>б) не имеет никакого отношения к Линку ВВ>Так яснее?
Ну, это ты у себя должен спросить. Это у тебя идиосинкразия на слово "функциональный" настолько сильная, что ты даже контекста не отслеживаешь, и про LINQ тут только ты говоришь. Вот и разберись, о чем это ты.. )
Ну и попробуй все-таки внимательно почитать, что тебе пишут, без нервов и истерик.
ВВ>А ты точно прочитал?
Да, Василий, в отличии от тебя, я это сделал..
ВВ>Объясни этому кому-нибудь другому. На сегодня я от тебя уже бреда наслушался.
Зря, возможно чему-нибудь научился бы и перестал бы пургу нести.. Хотя, с другой стороны, если я правильно помню, ты еще ООП не освоил, так что за функциональщину тебе пожалуй действительно рано браться..
Здравствуйте, IB, Вы писали:
ВВ>>Объясни этому кому-нибудь другому. На сегодня я от тебя уже бреда наслушался. IB>Зря, возможно чему-нибудь научился бы и перестал бы пургу нести.. Хотя, с другой стороны, если я правильно помню, ты еще ООП не освоил, так что за функциональщину тебе пожалуй действительно рано браться..
Вас видимо сильно мучают на работе, раз возникает желание с таким компентеным видом вдалбливать всем "пургу". Что ж, сочувствую. Попробуйте чаще использовать мозг — может, и жизнь тогда наладится.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Вас видимо сильно мучают на работе, раз возникает желание с таким компентеным видом вдалбливать всем "пургу". Что ж, сочувствую. Попробуйте чаще использовать мозг — может, и жизнь тогда наладится.
Эх, Василий... Если бы ты сам последовал своему совету, и применил свой мозг по назначению, хотя бы попытавшись понять, что тебе говорят, вместо того, чтобы неуклюже стараться уязвить оппонента во что бы то ни стало — глядишь бы и вышел толк... Но увы.
Здравствуйте, IB, Вы писали:
ВВ>>Вас видимо сильно мучают на работе, раз возникает желание с таким компентеным видом вдалбливать всем "пургу". Что ж, сочувствую. Попробуйте чаще использовать мозг — может, и жизнь тогда наладится. IB>Эх, Василий... Если бы ты сам последовал своему совету, и применил свой мозг по назначению, хотя бы попытавшись понять, что тебе говорят, вместо того, чтобы неуклюже стараться уязвить оппонента во что бы то ни стало — глядишь бы и вышел толк... Но увы.
Правда что ли, товарищ? Хамить почему-то всегда вы начинаете, видимо, считая, что ваше мнение уж настолько бесспорно, что любое потенциальное несогласие с ним — признак недалекого ума. Может, проще оставить свое мнение при себе, тогда и возражать никто не будет?
Если немножко подумать, что можно, наверное, заметить, что никакой по сути разницы между foreach и ForEach нет, кроме той самой "тонкой семантики замыкания", которая наблюдается еще в 22-х экстеншин методах вроде All, Count, Aggregate и пр., где за не фиг делать можно наплодить побочных эффектов и которые все-таки включили в пространство имен Linq. И то, что у вас, извините, выражение собственного мнения, что ForEach ни в каком виде не нужен, превращается в итоге в беседу в стиле "ты дурак", "нет, сам дурак", какой-то немножко характерный показатель, не находите?
Здравствуйте, Воронков Василий, Вы писали:
ВВ> Хамить почему-то всегда вы начинаете,
Я!? Упаси байт, никогда! =)
ВВ>Если немножко подумать,
Василий, не надо напрягатья, за тебя уже подумали... Вдвоем — Эрик и я..
ВВ>что можно, наверное, заметить, что никакой по сути разницы между foreach и ForEach нет, кроме той самой "тонкой семантики замыкания",
О! Налицо прогресс, с пятой попытки ты таки заметил еще один аргумент, браво! =) Огорчает только то, что ты похоже так и не понял первый... Ну да ладно, давай о другом, упростим задачу.
Ну, допустим, что между foreach и ForEach, как ты утверждаешь, разницы нет. Можешь ответить на вопрос — зачем в этом случае вводить новый, нестандартый, самописный метод, когда ровно то же самое можно сдеать совершенно стандартными средствами, которыми язык оборудован с рождения, и без неприятных побочных эффектов? При том что в емкости и выразительности стандартный способ, как минимум, не проигрывает?
Твою гениальную идею запихивания туда еще и предиката оставим пока за скобками, тебе все уже объяснили, правда я боюсь, что ты опять не понял.
ВВ> И то, что у вас, извините, выражение собственного мнения, что ForEach ни в каком виде не нужен, превращается в итоге в беседу в стиле "ты дурак", "нет, сам дурак", какой-то немножко характерный показатель, не находите?
Нет, Василий, это у тебя оно превратилось в беседу в таком стиле и поэтому я нахожу, что ты бревнышка в собственном глазу не замечаешь. И этот факт вполне вписывается в твою фантастическую способность полностью игнорировать написанное, если тебе оное не нравится. И вот это я нахожу очень характерным показателем.
чем интересно можно себя настолько зомбировать ("эрик! преклоняюсь перед тобой о светочЪ и истина в первой инстанции" (С) IB), чтобы нести нереальную пургу выдуманную исключительно в оправдание лени/тупости/индусости разработчиков BCL в отношении ForEach?
Label:
Читай что ли по слогам (ну конечно, в яслях читать еще не умеют): ForEach метод предназначен для обработки последовательности и не имеет Н И К А К О ГО отношения к linq. Ты способен это понять? Если нет, то goto (его осилишь?) Label;
Более того, ForEach может быть своим у последовательностей разных типов. Давай, вперед, используй циклы for — они же нии%ически доступны для понимания. Задайся вопросом (ну или почитай что-нибудь кроме липпппертов на досуге), почему в С++ STL есть for_each и его крайне рекомендуют использовать а не обходить последовательности вручную!
Здравствуйте, Аноним, Вы писали:
А>чем интересно можно себя настолько зомбировать ("эрик! преклоняюсь перед тобой о светочЪ и истина в первой инстанции" (С) IB), чтобы нести нереальную пургу выдуманную исключительно в оправдание лени/тупости/индусости разработчиков BCL в отношении ForEach?
Да, видимо уже модой стало считать себя умнее кучи разработчиков в MS.
А>Label: А>Читай что ли по слогам (ну конечно, в яслях читать еще не умеют): ForEach метод предназначен для обработки последовательности и не имеет Н И К А К О ГО отношения к linq. Ты способен это понять? Если нет, то goto (его осилишь?) Label;
Если ты так считаешь, то пиши свой ForEach, не запрещается. Другим доказывать ничего не надо.
А>Более того, ForEach может быть своим у последовательностей разных типов. Давай, вперед, используй циклы for — они же нии%ически доступны для понимания. Задайся вопросом (ну или почитай что-нибудь кроме липпппертов на досуге), почему в С++ STL есть for_each и его крайне рекомендуют использовать а не обходить последовательности вручную!
А причем тут for и C++? В C# есть стандартная конструкция foreach.
ЗЫ. В F# есть Seq.iter для прохода по коллекции, а for .. in может работать и как foreach, и как map. Никто пока не умер.
Re[19]: LINQ & Except
От:
Аноним
Дата:
13.06.09 15:18
Оценка:
Здравствуйте, gandjustas, Вы писали:
G>Да, видимо уже модой стало считать себя умнее кучи разработчиков в MS.
не пиши мне. читай липберта.
G>Если ты так считаешь, то пиши свой ForEach, не запрещается. Другим доказывать ничего не надо.
тебе лично я ничего не писал/не доказывал/etc.
btw, доказывает с пеной у рта тут только один человек — IB. нереально навязывает "правоту" мыслей либберта, несогласных пытается предать "анафеме" как иноверцев. вот к чему был мой пост.
G>А причем тут for и C++? В C# есть стандартная конструкция foreach.
правда? я не знал, спасибо что подсказал. юзай стандартный цикл for. он куда более стандартен, понятен, доступен
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, gandjustas, Вы писали:
G>>Да, видимо уже модой стало считать себя умнее кучи разработчиков в MS. А>не пиши мне. читай липберта.
Это тебе стоит прочитать этот пост. Особенно последнюю строчку
Если вы не согласны с этими философскими возражениями и находите в этом приёме практическую ценность, определенно не сдерживайте себя и напишите эту тривиальную строчку сами.
G>>А причем тут for и C++? В C# есть стандартная конструкция foreach. А>правда? я не знал, спасибо что подсказал. юзай стандартный цикл for. он куда более стандартен, понятен, доступен
Это уже бред воспаленного воображения.
Мы уже победили, просто это еще не так заметно...
