S>>>(стакан / чай).Мешать(ложка)
G>>Твой вариант будет
G>>Движения.Мешать(Операции.Налить(стакан, чай), ложка)
G>>Где внимание акцентировано на операциях. В итоге получаем театральную чайную церемонию и чай из пакетика. Если нам важна церемония, то это хорошо, если важен чай, то это плохо. Если важен чай, то его и нужно ставить на первое место. S>Удивительно что тебя не смутил тип результата комбинирования стакана и чая. Главное поставить вперед перед "мешать" этакое сужение контекста.
Мы что тут обсуждаем? Оба варианты предложил ты, поэтому все претензии по типу результата к тебе. Я же отвечаю только про порядок аргументов и операций для их понимания.
Здравствуйте, grosborn, Вы писали:
S>>>>(стакан / чай).Мешать(ложка)
G>>>Твой вариант будет
G>>>Движения.Мешать(Операции.Налить(стакан, чай), ложка)
S>>Удивительно что тебя не смутил тип результата комбинирования стакана и чая. Главное поставить вперед перед "мешать" этакое сужение контекста.
G>Мы что тут обсуждаем? Оба варианты предложил ты, поэтому все претензии по типу результата к тебе. Я же отвечаю только про порядок аргументов и операций для их понимания.
тогда ответь как порядок (стакан /чай) влияет на понимание операции "мешать". С файлами и чемоданами что-то не вышло у тебя убедительности.
Здравствуйте, grosborn, Вы писали:
G>File.Copy(Path.Combine(path1, path2), path); G>// против G>path1.Combine(path2).FileCopy(path);
Первая строка выглядит намного логичнее: у файла есть операция копирования, очевидно, нуждающаяся в двух равнозначных вещах: откуда, куда. Откуда — более сложный аргумент, конструирующий путь — опять же из двух и более кусков полного пути. Читая же вторую строку, вижу: есть путь файла, его скомбинировали с другим — ок, значит на выходе мы имеем полный путь. Но почему вдруг у пути должен быть метод "копировать файл"?? Путь вообще-то строка, более того — путь может указывать вообще на каталог! Как к каталогу можно применять ФилеЦопи?? Вот эта ментальная закавыка говорит только об одном — отстойном проектировании отношений: смешали в кучу коней, людей, на выходе — Бородино, млин!
G>// или еще лучше G>(path1 / path2).FileCopy(path);
Что это за операция "путь делить на путь"? И почему /, а не \ ?
G>Linq работает, функциональный стиль. В общем получается читабельный код, а не макаронник.
Вобщем, кому-то чешется наприменять всякой ерундистики безо всякого вдумчивого проектирования и учёта стандартных соглашений. ФП — это пузырь, запишите и не пихайте его во невпихуемое.
S>тогда ответь как порядок (стакан /чай) влияет на понимание операции "мешать". С файлами и чемоданами что-то не вышло у тебя убедительности.
Надоело.
Ты лучше скажи что тебе показалось в проверке эквивалентности "из рук вон плохо". Я там исправил одну опечатку. Ты готов назвать какой-то конкретный недочет в алгоритме? Мне очень интересно что же там тебе лично не понравилось. Или твои претензии того же плана что и вся дискуссия в этой ветке, что аргументы не в том порядке и это и есть из рук вон плохо?
Здравствуйте, grosborn, Вы писали:
S>>тогда ответь как порядок (стакан /чай) влияет на понимание операции "мешать". С файлами и чемоданами что-то не вышло у тебя убедительности.
G>Надоело. G>Ты лучше скажи что тебе показалось в проверке эквивалентности "из рук вон плохо". Я там исправил одну опечатку. Ты готов назвать какой-то конкретный недочет в алгоритме? Мне очень интересно что же там тебе лично не понравилось. Или твои претензии того же плана что и вся дискуссия в этой ветке, что аргументы не в том порядке и это и есть из рук вон плохо?
Уже указывал на несоответствие требований к реализации CompareTo и Equals
Здравствуйте, grosborn, Вы писали:
S>>Уже указывал на несоответствие требований к реализации CompareTo и Equals
G>Нет, не указывал. Ты сказал что есть несоответствие. Но тесты показывает обратное.
Тесты я не смотрел, но вот строчка в функции Equals
if (Empty)
return false;
в моем понимании противоречит рефлексивности.
А так же
if (Empty)
return -1/*???*/;
в функции CompareTo(object)
Так же финальный "return 0" в CompareTo означает что объект будет равен всему, что не PathInfo и не строка. Т.е. равен 1-е, списку, словарю и т.п. А это ломает симметричность, т.к. вряд ли все остальные объекты будут думать так же по поводу твоего PathInfo.
Вобщем, налицо полнейшее непонимание механики отношения порядка.
Здравствуйте, samius, Вы писали:
S>Так же финальный "return 0" в CompareTo означает что объект будет равен всему, что не PathInfo и не строка. Т.е. равен 1-е, списку, словарю и т.п. А это ломает симметричность, т.к. вряд ли все остальные объекты будут думать так же по поводу твоего PathInfo.
Собственно еще тот факт что твой путь может быть равен некоторй строке тоже портит малину, ведь строка не будет считать себя равной твоему пути.
Вот да, путь он такой, список файлов это неотъемлемое его свойство, и у пути к каталогу и у пути к файлу. И соответственно теоретически для пути будут доступны групповые операции и операции над множествами, всякие богомерзкие enumerable, linq и все такое, вот гадость-то прости хоспади. Гораздо проще один файл прибитый гвоздями, согласен.
M>Вот эта ментальная закавыка говорит только об одном — отстойном проектировании отношений: смешали в кучу коней, людей, на выходе — Бородино, млин!
Вся эта ментальная закавыка возникла у тебя. А у меня это много лет пользуется без ментальных закавык.
M>Вобщем, кому-то чешется наприменять всякой ерундистики безо всякого вдумчивого проектирования и учёта стандартных соглашений. ФП — это пузырь, запишите и не пихайте его во невпихуемое.
Че к чему? Оно работает и удобно. Чего ты тут не смог впихнуть?
S>>Так же финальный "return 0" в CompareTo означает что объект будет равен всему, что не PathInfo и не строка. Т.е. равен 1-е, списку, словарю и т.п. А это ломает симметричность, т.к. вряд ли все остальные объекты будут думать так же по поводу твоего PathInfo.
S>Собственно еще тот факт что твой путь может быть равен некоторй строке тоже портит малину, ведь строка не будет считать себя равной твоему пути.
А ты попробуй предположить в каких ситуациях такой вызов возникнет? А вот то-то и оно. Синтаксически строка и не вызовет никогда этот метод для сравнения с собой, ибо. А вот сравнивать мой объект со строкой я могу и только в этом случае вызывается этот метод с таким параметром. Хотя можно и вырезать, для простоты и понятности, не определилися я еще, нужно практику применения проверить.
Идея интересная.
Но так и не ясно чем ваш код лучше альтернатив которые вы же и привели.
Насчет Path.Copy(a, b) против new PathInfo(a).Copy(b)
Есть ведь FileInfo.CopyTo который дублирует Path.Copy как раз это и делает.
При чем делает это так: new FileInfo("source").CopyTo("dest")
Некоторые замечания:
Файл на 3000 строк ? Может стоить разделить ?
Нужна явно документация с аргументированием зачем нужно то или это.
Скажем, что означает операция больше для PathInfo ?
Вот "a" меньше "a/" ?
А сравнить "a" и "a/../a" , что больше ?
Я о том что семантика сравнения не всегда очевидна.
Кстати в boost::filesystem тоже используют '/' для конкатенации путей.
Операция "&" это интересно, но как-то не очевидно , почему не "|" тогда ?
BulkException это аналог AggregateException ?
(temp & "*.tmp").Bulk(...)
Чем плох foreach ?
Какое назначение у PathList ? Чем он лучше MyContainer<PathInfo> ?
Некоторые методы вообще неясны как FileWriteAllLines .
Чем лучше
new PathInfo("a").FileWriteAllLines(new string[]{"a","b"});
от
File.WriteAllLines("a", new string[]{"a","b"));
Здравствуйте, grosborn, Вы писали:
S>>Собственно еще тот факт что твой путь может быть равен некоторй строке тоже портит малину, ведь строка не будет считать себя равной твоему пути.
G>А ты попробуй предположить в каких ситуациях такой вызов возникнет? А вот то-то и оно. Синтаксически строка и не вызовет никогда этот метод для сравнения с собой, ибо. А вот сравнивать мой объект со строкой я могу и только в этом случае вызывается этот метод с таким параметром. Хотя можно и вырезать, для простоты и понятности, не определилися я еще, нужно практику применения проверить.
То есть тебе мало того что я указал на несоответствие требованиям, так еще и тесты для тебя выдумать?
Ну ладно. По косяку со сравнению со строками:
Array.IndexOf(new []{new PathInfo("path1")}, "path1")
или наоборот.
По косяку с отсутствием рефлексивности конкретный пример придумать сложнее, но направление могу дать. Массив, в котором более одного Empty путя после выполнения сортировки может быть не отсортирован.
Если ситуация с поиском строки в массиве путей сомнительна, то это конкретный ахтунг.
Так же будет сбоить проверка наличия пустого пути в хэштаблице.
_NN>Идея интересная. _NN>Но так и не ясно чем ваш код лучше альтернатив которые вы же и привели. _NN>Насчет Path.Copy(a, b) против new PathInfo(a).Copy(b) _NN>Есть ведь FileInfo.CopyTo который дублирует Path.Copy как раз это и делает. _NN>При чем делает это так: new FileInfo("source").CopyTo("dest")
В плане синтаксиса просто получается более чистый и компактный код, за счет того что выражение операции или команды можно написать как классически File.Copy(), (так и после длинного селектора).FileCopy()
В остальном нужно понимать что это будет процентов на 80% простой порт этих всех функций в дополнение к добавляемым в самом объекте, просто что бы обеспечить монолитность и завершенность этого класса и исключить необходимость обращения скажем к System.IO.Path
_NN>Некоторые замечания: _NN>Файл на 3000 строк ? Может стоить разделить ?
Модуль-то? Идея в том что его можно скопировать и просто вставить в проект, одним файлом. Для упрощения его использования. Если будет несколько какой-то может потеряться.
_NN>Нужна явно документация с аргументированием зачем нужно то или это. _NN>Скажем, что означает операция больше для PathInfo ? _NN>Вот "a" меньше "a/" ? _NN>А сравнить "a" и "a/../a" , что больше ? _NN>Я о том что семантика сравнения не всегда очевидна.
Поскольку это сравнение двух путей, то сравнение идет начиная с корневого каталога и дальше вниз и если на каком-то уровне неравенство это и будет результат. Это общее правило сравнения файловых путей. z:\a.txt > a:\z.txt потому что z: > a: как-то так.
_NN>Кстати в boost::filesystem тоже используют '/' для конкатенации путей. _NN>Операция "&" это интересно, но как-то не очевидно , почему не "|" тогда ?
У шарпа немного операторов которые можно перегрузить и они имеют фиксированный порядок выполнения. "|" тут просто не получится, будут возникать синтаксические ошибки в сложных выражениях.
_NN>BulkException это аналог AggregateException ?
Почти. На одно поле больше по причине адаптации к предметной области. Делать ли его наследником AggregateException я пока не сообразил нужно ли.
_NN>
_NN> (temp & "*.tmp").Bulk(...)
_NN>
_NN>Чем плох foreach ?
Ничем. Можно и foreach. Точнее если нужно что бы операция остановилась на первой же ошибке, то foreach, иначе AggregateException или вот этот булк задумывался для упрощения синтаксиса обработки файловых ошибок.
_NN>Какое назначение у PathList ? Чем он лучше MyContainer<PathInfo> ?
Операции над множествами. Нужен отдельный тип для применения операторов и это будет как специализированная коллекция. Отношения владелец-подчиненный тут не возникает, просто селекторы и множества. PathList — множество.
_NN>Некоторые методы вообще неясны как FileWriteAllLines . _NN>Чем лучше _NN>new PathInfo("a").FileWriteAllLines(new string[]{"a","b"}); _NN>от _NN>File.WriteAllLines("a", new string[]{"a","b")); _NN>
Да они не лучше, это просто разный синтаксис. В разных ситуациях дает разную экономию кода. Где-то namespace протаскивать не нужно, где-то если класс унаследован от PathInfo убираются лишние обращения через точку, где-то будут добавляться селекторы к этим методам еще для выполнения групповых операций над файлами, что уберет код перечисления и агрегации исключения из пользовательского кода.
Здравствуйте, grosborn, Вы писали:
G>Тогда такой вопрос уточняющий: ты предлагаешь убрать вот это соглашение об эквивалентности двух пустых объектов: G>Empty == Empty ?
Нет, я не предлагаю это. Я предлагаю наоборот что бы они были эквивалентны.
G>Но это приведет к необходимости создавать некий аналог string.Empty и оверхеду в коде сравнения.
чиво?
G>>Тогда такой вопрос уточняющий: ты предлагаешь убрать вот это соглашение об эквивалентности двух пустых объектов: G>>Empty == Empty ? S>Нет, я не предлагаю это. Я предлагаю наоборот что бы они были эквивалентны.
Так они эквивалентны, тут все нормально. Не понимаю о чем ты.
Сравнение со строкой я все-таки уберу наверное, тут ты прав про коммутативность. Хотя это нигде не мешает, но если быть педантичным то нужно убирать.
Здравствуйте, grosborn, Вы писали:
G>>>Тогда такой вопрос уточняющий: ты предлагаешь убрать вот это соглашение об эквивалентности двух пустых объектов: G>>>Empty == Empty ? S>>Нет, я не предлагаю это. Я предлагаю наоборот что бы они были эквивалентны.
G>Так они эквивалентны, тут все нормально. Не понимаю о чем ты.
public int CompareTo(object obj)
{
// Сравнивать нужно последовательно по фрагментам пути?
// Пока так:if ((object)obj == null)
return (Empty) ? 0 : 1/*???*/;
if (Empty)
return -1/*???*/;
Твой код? Если да, то будут ли два путя со свойством Empty эквивалентны?
G>Сравнение со строкой я все-таки уберу наверное, тут ты прав про коммутативность. Хотя это нигде не мешает, но если быть педантичным то нужно убирать.
и сравнение с любыми другими типами не помешает убрать.
Странный трэд получается... Выходит товарищ grosborn с решением несуществующей проблемы и заявляет:
"Это враппер... и дополнительные плюшки.", "Прошу посмотреть и сказать мне, нужно ли это допиливать до совершенства или забросить куда подальше."
Начинаются терпеливые объяснения почему код выглядит алогичным и почему этот проект надо, КАК И ПРЕДЛАГАЛОСЬ, "забросить куда подальше." Вместо восприятия аргументов, отважный Наполеон начинает усираться с защитой своей кривой логики, прикрываясь пузырём функциональщины и типа "экономии символов". Может, пора уже остыть, товарищ? Вас никто здесь за гения не держит, можно расслабиться — выкиньте свой враппер и возьмитесь за задачи, которые действительно могли бы быть полезны. Например, диалог открытия файла в WPF — его до сих пор нет.
Здравствуйте, grosborn, Вы писали:
G>В плане синтаксиса просто получается более чистый и компактный код, за счет того что выражение операции или команды можно написать как классически File.Copy(), (так и после длинного селектора).FileCopy()
Кроме компактности должна быть и выразительность.
А делать обертки для File.Read в виде метода ReadFile как-то смшено.
_NN>>Некоторые замечания: _NN>>Файл на 3000 строк ? Может стоить разделить ?
G>Модуль-то? Идея в том что его можно скопировать и просто вставить в проект, одним файлом. Для упрощения его использования. Если будет несколько какой-то может потеряться.
Для упрощения использования есть проект или пакет NuGet , а сколько там файлов не так важно.
G>Поскольку это сравнение двух путей, то сравнение идет начиная с корневого каталога и дальше вниз и если на каком-то уровне неравенство это и будет результат. Это общее правило сравнения файловых путей. z:\a.txt > a:\z.txt потому что z: > a: как-то так.
На мой взгляд это не нужно реализовывать в самом PathInfo.
Пусть будет PathInfoComparer, PathInfoExpandedPathComparer , ведь есть несколько способ сравнивать и неясно что из этого лучше.
G>У шарпа немного операторов которые можно перегрузить и они имеют фиксированный порядок выполнения. "|" тут просто не получится, будут возникать синтаксические ошибки в сложных выражениях.
А с '&' не будет ? У вас есть пример ?
Разницы между a & "*.tmp" и a.Files("*.tmp") не так много, а код понятней.
G>Почти. На одно поле больше по причине адаптации к предметной области. Делать ли его наследником AggregateException я пока не сообразил нужно ли.
Логично воспользоваться тем что дают.
G>Ничем. Можно и foreach. Точнее если нужно что бы операция остановилась на первой же ошибке, то foreach, иначе AggregateException или вот этот булк задумывался для упрощения синтаксиса обработки файловых ошибок.
Вот метод 'Bulk' не нужно добавлять в PathInfo.
Кому надо добавят свой аналог если еще не написали.
G>Да они не лучше, это просто разный синтаксис. В разных ситуациях дает разную экономию кода. Где-то namespace протаскивать не нужно, где-то если класс унаследован от PathInfo убираются лишние обращения через точку, где-то будут добавляться селекторы к этим методам еще для выполнения групповых операций над файлами, что уберет код перечисления и агрегации исключения из пользовательского кода.
using System.IO;
Это 100% экономия Решарпер сам вставит за вас этот код не напрягаясь.
Зачем наследоваться от PathInfo ?
Я бы его сделал запечатанным (sealed) как раз.
