Здравствуйте, 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>Сравнение со строкой я все-таки уберу наверное, тут ты прав про коммутативность. Хотя это нигде не мешает, но если быть педантичным то нужно убирать.
и сравнение с любыми другими типами не помешает убрать.

В общем вот GitHub PathInfo.cs простой модуль. Оформлено примерно до 80-90% готовности, но основные вещи используются уже давно.
Это враппер для System.IO.Path, File, Directory, их полный 100% порт в объект PathInfo и дополнительные плюшки.
Ближайшие аналоги которые я нашел FluentPath и NDepend.Helpers, если кто еще найдет прошу мне подсказать.
Обязательно к применению абсолютно во всех проектах, с этим модулем у вас поднимется урожайность, производительность, продуктивность и плодовитость, повысятся надои, увеличатся бегучесть, плывучесть и прыгучесть. Ждем включения в следующую версию фреймворка.
Код будет компактнее и понятнее.
Прошу посмотреть и сказать мне, нужно ли это допиливать до совершенства или забросить куда подальше.

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

S>>А зачем тогда нужен FileCopy? Он это делает лучше чем File.Copy?

G>Легче читается нотация файловых операций.
Не уверен на 100%

G>File.Copy(Path.Combine(path1, path2), path);
Отлично

G>// против

G>path1.Combine(path2).FileCopy(path);
G>// или еще лучше
G>(path1 / path2).FileCopy(path);

G>лучше воспринимается, быстрее набор кода через автодополнение. Linq работает, функциональный стиль. В общем получается читабельный код, а не макаронник.
Мне сложно воспринимать семантику Путь.КопируйФайл(путь). Сложнее разве что только Строка.КопируйФайл(строка).
Линк работает и без этого кода, а для функционального стиля слишком много императива.

G>>Что-то я не совсем понял. Так ты предлагаешь запилить диалог в надежде что мелкомягкие выкатят что-то в чем этот диалог понадобится?

M>Не распарсил вопрос.

По другому спрошу.
Такой диалог нужен сейчас, системный не устраивает по каким-то причинам? Каким?
Или он сейчас не очень-то и нужен, но может понадобиться если "выкатят завтра"?

Я к тому что ожидать что мелкомягкие что-то завтра выкатят не стоит, последнее время они только закатывают, но никак не выкатывают. У них сейчас засилье отстойного квадратного дизайна, шок от ошеломляющего успеха восьмой венды, облачность мозга, им не до новинок. Или же ты надеешься что выкатит кто-то другой и что-то другое? В общем икры ты тут наметал, хочется немного пояснений зачем этот диалог нужен.

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

G>В общем вот GitHub PathInfo.cs простой модуль.
фигасе простой
G>Прошу посмотреть и сказать мне, нужно ли это допиливать до совершенства или забросить куда подальше.
Я бы забросил. Но если вдруг решитесь допиливать — как минимум CompareTo и Equals реализованы из рук вон плохо, будут ломать сортировку на раз.

G>>В общем вот GitHub PathInfo.cs простой модуль.
S>фигасе простой
G>>Прошу посмотреть и сказать мне, нужно ли это допиливать до совершенства или забросить куда подальше.
S>Я бы забросил. Но если вдруг решитесь допиливать — как минимум CompareTo и Equals реализованы из рук вон плохо, будут ломать сортировку на раз.

Если я это два дня пилил, то завтра могу остальное запилить если не лень будет.

CompareTo и Equals

вроде бы проверял на эффективность, а что там не так? Сортировка она же ведь не по полному пути, а на каждом уровне. Конкретно этот код сравнения я вчера написал и действительно он еще не обкатан и не доведен до блеска. Можешь свои замечания сказать?

Он простой в том смысле, что если ты знаешь Path,File и Directory, то ты знаешь все и про этот модуль, ибо он 100% порт. То есть ты помнишь что есть такой статик метод File.Copy(,) -> у PathInfo всем им есть полный аналог их вызывающий, это FileCopy(). то есть ничего нового изучать не требуется.

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

G>вроде бы проверял на эффективность, а что там не так? Сортировка она же ведь не по полному пути, а на каждом уровне. Конкретно этот код сравнения я вчера написал и действительно он еще не обкатан и не доведен до блеска. Можешь свои замечания сказать?
Дело не в эффективности, а в ошибке реализации логики.
Замечания не мои, они MSDN-овские.
Вот, например http://msdn.microsoft.com/en-us/library/system.icomparable.compareto.aspx, см. Notes to Implementers.
Еще ближе:

If A.CompareTo(B) returns a value other than zero, then B.CompareTo(A) must return a value of the opposite sign.

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

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

G>Он простой в том смысле, что если ты знаешь Path,File и Directory, то ты знаешь все и про этот модуль, ибо он 100% порт. То есть ты помнишь что есть такой статик метод File.Copy(,) -> у PathInfo всем им есть полный аналог их вызывающий, это FileCopy(). то есть ничего нового изучать не требуется.
А зачем тогда нужен FileCopy? Он это делает лучше чем File.Copy?

S>Это условие не выполнится в случае сравнения двух путей, у которых Empty true. Это то что в глаза бросилось, полное соответствие требованиям я не проверял.

Сейчас закину в тест-модуль пару строк и проверю.

G>>Он простой в том смысле, что если ты знаешь Path,File и Directory, то ты знаешь все и про этот модуль, ибо он 100% порт. То есть ты помнишь что есть такой статик метод File.Copy(,) -> у PathInfo всем им есть полный аналог их вызывающий, это FileCopy(). то есть ничего нового изучать не требуется.
S>А зачем тогда нужен FileCopy? Он это делает лучше чем File.Copy?


Легче читается нотация файловых операций.

File.Copy(Path.Combine(path1, path2), path);

// против

path1.Combine(path2).FileCopy(path);
// или еще лучше
(path1 / path2).FileCopy(path);

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

S>If A.CompareTo(B) returns a value other than zero, then B.CompareTo(A) must return a value of the opposite sign.

Ну вроде бы теперь тестами все покрыто.

Приняты такие допущения
null != null — это строго по гайдам
Empty > null
Empty == Empty — это для поиска пустых значений в списках

И что характерно, теперь реквизит объекта можно назвать "Path":

public PathInfo Path;

раньше Path нельзя было сделать потому что тогда приходилось к классу Path обращаться через System.IO.Path

G>>лучше воспринимается, быстрее набор кода через автодополнение. Linq работает, функциональный стиль. В общем получается читабельный код, а не макаронник.
S>Мне сложно воспринимать семантику Путь.КопируйФайл(путь). Сложнее разве что только Строка.КопируйФайл(строка).
S>Линк работает и без этого кода, а для функционального стиля слишком много императива.

Но против уменьшения количества буковок ты же не сможешь возразить? Экономия до 10-50 символов в строке в новой нотации. Ну же, соглашайся?

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

G>>>лучше воспринимается, быстрее набор кода через автодополнение. Linq работает, функциональный стиль. В общем получается читабельный код, а не макаронник.
S>>Мне сложно воспринимать семантику Путь.КопируйФайл(путь). Сложнее разве что только Строка.КопируйФайл(строка).
S>>Линк работает и без этого кода, а для функционального стиля слишком много императива.

G>Но против уменьшения количества буковок ты же не сможешь возразить? Экономия до 10-50 символов в строке в новой нотации. Ну же, соглашайся?
можно пример с экономией в 50 буковок? Только не надо писать Path.Combine(Path.Combine(Path.Combine(...)))

Экономия на буковках ценой семантики — идея не очень. Да и если прижмет сэкономить, мне не долго написать пару методов хелперов.

G>>>>лучше воспринимается, быстрее набор кода через автодополнение. Linq работает, функциональный стиль. В общем получается читабельный код, а не макаронник.
S>>>Мне сложно воспринимать семантику Путь.КопируйФайл(путь). Сложнее разве что только Строка.КопируйФайл(строка).
S>>>Линк работает и без этого кода, а для функционального стиля слишком много императива.

А где-нибудь в твоих проектах есть примеры работы с путями или именами фалов? Может ты запостишь кусочек, я перепишу и посмотрим.


G>>Но против уменьшения количества буковок ты же не сможешь возразить? Экономия до 10-50 символов в строке в новой нотации. Ну же, соглашайся?
S>можно пример с экономией в 50 буковок? Только не надо писать Path.Combine(Path.Combine(Path.Combine(...)))

Нет, я взял пример из предыдущей своей ветки

public static readonly string USER_DATA_DIR = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData), "Kotonoha");

иногда эти портянки довольно велики, а с переносами и вообще нечитаемы.


S>Экономия на буковках ценой семантики — идея не очень.

Лично я считаю читабельность кода важнее. Но просто ты по своим предпочтением завалил все остальные мои аргументы и читабельность тебя почему-то не впечатлила. Остались только буковки.


S>Да и если прижмет сэкономить, мне не долго написать пару методов хелперов.

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

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

S>>>>Линк работает и без этого кода, а для функционального стиля слишком много императива.

G>А где-нибудь в твоих проектах есть примеры работы с путями или именами фалов? Может ты запостишь кусочек, я перепишу и посмотрим.
Ничего экстраординарного.

S>>можно пример с экономией в 50 буковок? Только не надо писать Path.Combine(Path.Combine(Path.Combine(...)))

G>Нет, я взял пример из предыдущей своей ветки

G>

G>public static readonly string USER_DATA_DIR = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData), "Kotonoha");
G>

о, показательный пример. Обсудим.
Итак, первая часть — несокращаемая. Это "public static readonly string". Ну там можно сократить разве что до "public static readonly Path", но это не спортивно, т.к. строку тоже можно using-ом во что-то перекроить.
Дальше Path.Combine. Не самая длинная часть, предлагаю ее пока оставить как есть.
Вот по поводу Environment.GetFolderPath(...) и Environment.SpecialFolder.LocalApplicationData — тут я поддерживаю, это немного избыточно. Я бы оставил Environment.SpecialFolders.LocalApplicationData. Причем, не уверен что это вообще касается Environment BCL, т.к. фреймворк-то задумывался как межплатформенный. В идеале было бы что-то вроде Microsoft.Windows.SpecialFolders.LocalApplicationData, причем Microsoft.Windows — это namespace, SpecialFolders — класс, а LocalApplicationData — статическое свойство. Enum тоже нужен, и GetFolderPath с ним нужен, но для специальных случаев. А когда мы точно знаем что путь будет LocalApplicationData, GetFolderPath избыточен.

Итак, в идеале мой код был бы такой:

using Microsoft.Windows;

public static readonly string USER_DATA_DIR =
    Path.Combine(SpecialFolders.LocalApplicationData, "Kotonoha");

И для него достаточно лишь "выпрямить" SpecialFolders.
Понятно, что можно сэкономить за счет SpecialFolders.LocalApplicatoinData.Combine("Kotonoha"), но я не поклонник таких экономий. К слову сказать, enumerable1.Combine(enumerable2) мне тоже не нравится и я часто пишу Enumerable.Combine(enumerable1, enumerable2).

G>иногда эти портянки довольно велики, а с переносами и вообще нечитаемы.
Есть хороший прием, называется Introduce Local. Со статическими перменными тоже работает.


S>>Экономия на буковках ценой семантики — идея не очень.

G>Лично я считаю читабельность кода важнее. Но просто ты по своим предпочтением завалил все остальные мои аргументы и читабельность тебя почему-то не впечатлила. Остались только буковки.
Читабельность не выражается в 1/(число буковок).

S>>Да и если прижмет сэкономить, мне не долго написать пару методов хелперов.

G>Идеи с хелперами мне всегда не нравились потому что если это хелпер к строке пути, то мы загрязняем методами расширения строку, что потом лезет везде в автодополнение во всех местах. Поэтому расширения строки не использую.
Поддерживаю. Хотя, по началу любил юзать "[{0}]".Format(someValue) вместо String.Format(....
Но потом и это отпало.

S>Итак, в идеале мой код был бы такой:
S>

S>using Microsoft.Windows;

S>public static readonly string USER_DATA_DIR =
S>    Path.Combine(SpecialFolders.LocalApplicationData, "Kotonoha");
S>

S>И для него достаточно лишь "выпрямить" SpecialFolders.
S>Понятно, что можно сэкономить за счет SpecialFolders.LocalApplicatoinData.Combine("Kotonoha"), но я не поклонник таких экономий. К слову сказать, enumerable1.Combine(enumerable2) мне тоже не нравится и я часто пишу Enumerable.Combine(enumerable1, enumerable2).

Это то чего нет, но хотелось бы. А вот что есть:

var example1 = PathInfo.APPLICATION_DATA_LOCAL / "Kotonoha";

PathInfo example2 = Environment.SpecialFolder.LocalApplicationData; 
    example2 /= "Kotonoha"; // Изврат

var example3 = (PathInfo)Environment.SpecialFolder.LocalApplicationData / "Kotonoha";

var example4 = PathInfo.APPLICATION_DATA_LOCAL.Combine("Kotonoha");

Самый близкий к твоему варианту предпоследний.



G>>иногда эти портянки довольно велики, а с переносами и вообще нечитаемы.
S>Есть хороший прием, называется Introduce Local. Со статическими перменными тоже работает.

Не совсем понял о чем ты.



S>Поддерживаю. Хотя, по началу любил юзать "[{0}]".Format(someValue) вместо String.Format(....
S>Но потом и это отпало.

Та же беда. Но если бы "[{0}]".Format(someValue) был искаробки, то я бы предпочел им пользоваться, а не String.Format(

S>И для него достаточно лишь "выпрямить" SpecialFolders.
S>Понятно, что можно сэкономить за счет SpecialFolders.LocalApplicatoinData.Combine("Kotonoha"), но я не поклонник таких экономий. К слову сказать, enumerable1.Combine(enumerable2) мне тоже не нравится и я часто пишу Enumerable.Combine(enumerable1, enumerable2).


Тут ты неправ. Для читабельности кода строка начинающаяся с Enumerable.Combine( и Path.Combina( сильно вредит. Строка должна начинаться со смысловой нагрузки сужающей контекст, а не с глобального метода понять который мы можем только прочитав его аргументы.
Начало выражения Enumerable.Combine( не сужает контекст выбора и для понимания и для подсказки автовыбора, а начало выражения с первого аргумента сужает. Так что тут ты объективно не прав.

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

S>>Понятно, что можно сэкономить за счет SpecialFolders.LocalApplicatoinData.Combine("Kotonoha"), но я не поклонник таких экономий. К слову сказать, enumerable1.Combine(enumerable2) мне тоже не нравится и я часто пишу Enumerable.Combine(enumerable1, enumerable2).

G>Это то чего нет, но хотелось бы. А вот что есть:


G>

G>var example1 = PathInfo.APPLICATION_DATA_LOCAL / "Kotonoha";

G>PathInfo example2 = Environment.SpecialFolder.LocalApplicationData; 
G>    example2 /= "Kotonoha"; // Изврат

G>var example3 = (PathInfo)Environment.SpecialFolder.LocalApplicationData / "Kotonoha";

G>var example4 = PathInfo.APPLICATION_DATA_LOCAL.Combine("Kotonoha");
G>

G>Самый близкий к твоему варианту предпоследний.
Они почти все (кроме 2) близки с точностью до вызова Combine (места либо отсутствия вызова).

G>>>иногда эти портянки довольно велики, а с переносами и вообще нечитаемы.
S>>Есть хороший прием, называется Introduce Local. Со статическими перменными тоже работает.

G>Не совсем понял о чем ты.
http://www.jetbrains.com/resharper/webhelp/Refactorings__Introduce_Variable.html

S>>Поддерживаю. Хотя, по началу любил юзать "[{0}]".Format(someValue) вместо String.Format(....
S>>Но потом и это отпало.

G>Та же беда. Но если бы "[{0}]".Format(someValue) был искаробки, то я бы предпочел им пользоваться, а не String.Format(
угу

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

S>>И для него достаточно лишь "выпрямить" SpecialFolders.
S>>Понятно, что можно сэкономить за счет SpecialFolders.LocalApplicatoinData.Combine("Kotonoha"), но я не поклонник таких экономий. К слову сказать, enumerable1.Combine(enumerable2) мне тоже не нравится и я часто пишу Enumerable.Combine(enumerable1, enumerable2).


G>Тут ты неправ. Для читабельности кода строка начинающаяся с Enumerable.Combine( и Path.Combina( сильно вредит. Строка должна начинаться со смысловой нагрузки сужающей контекст, а не с глобального метода понять который мы можем только прочитав его аргументы.
G>Начало выражения Enumerable.Combine( не сужает контекст выбора и для понимания и для подсказки автовыбора, а начало выражения с первого аргумента сужает. Так что тут ты объективно не прав.
не понял в чем я не прав. Path.Combine прекрасно сужает контекст. Что бы понять, что он делает, вовсе не обязательно читать аргументы.
Автовыбор меня мало беспокоит, т.к. я код больше читаю чем пишу.
Повторюсь. Путь.Комбинируйся с другим путем для меня — порно. Так же как и Путь.КопируйФайл(другойПуть). Так же как и объект.Сравнись(другойОбъект).
Вот путь / другойПуть — это хорошо. Но ради этого не стоит писать столько кода. Префиксная запись не сильно хуже в данном случае.

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

G>Тут ты неправ. Для читабельности кода строка начинающаяся с Enumerable.Combine( и Path.Combina( сильно вредит. Строка должна начинаться со смысловой нагрузки сужающей контекст, а не с глобального метода понять который мы можем только прочитав его аргументы.
G>Начало выражения Enumerable.Combine( не сужает контекст выбора и для понимания и для подсказки автовыбора, а начало выражения с первого аргумента сужает. Так что тут ты объективно не прав.

Чуть отвлекись от программинга, взгляни на проблему шире, с другой точки зрения.
Когда мы видим математическое выражение 2 + 3, то часто так и произносим: "два плюс три". Но часто говорим по-другому: "сложить два и три". Ведь так? Объективно? Теперь переведём второе выражение в код: сложить(2, 3), то есть Path.Combine...

G>>Тут ты неправ. Для читабельности кода строка начинающаяся с Enumerable.Combine( и Path.Combina( сильно вредит. Строка должна начинаться со смысловой нагрузки сужающей контекст, а не с глобального метода понять который мы можем только прочитав его аргументы.
G>>Начало выражения Enumerable.Combine( не сужает контекст выбора и для понимания и для подсказки автовыбора, а начало выражения с первого аргумента сужает. Так что тут ты объективно не прав.

K>Чуть отвлекись от программинга, взгляни на проблему шире, с другой точки зрения.
K>Когда мы видим математическое выражение 2 + 3, то часто так и произносим: "два плюс три". Но часто говорим по-другому: "сложить два и три". Ведь так? Объективно? Теперь переведём второе выражение в код: сложить(2, 3), то есть Path.Combine...

Часто говорят "сложить два плюс три", что как бэ намекает.

Зачем мне отвлекаться? Это у вас в голове префиксная нотация сидит. Она не является общепринятой именно по тем причинам что я указал, начинается с знака операции, а не аргумента, и сложнее для чтения и понимания результата, акцентирует на операции. Общепринятая же форма 5 − (6 * 7). А есть еще такая * − 5 6 7. Если тебе нравится последняя форма записи, это не значит учто она должна быть у всех, большинство предпочитает инфиксную.
Префиксная запись имеет смысл только в случае когда операция для понимания важнее чем аргумент и она одна в строке.

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

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

S>>>И для него достаточно лишь "выпрямить" SpecialFolders.
S>>>Понятно, что можно сэкономить за счет SpecialFolders.LocalApplicatoinData.Combine("Kotonoha"), но я не поклонник таких экономий. К слову сказать, enumerable1.Combine(enumerable2) мне тоже не нравится и я часто пишу Enumerable.Combine(enumerable1, enumerable2).


G>>Тут ты неправ. Для читабельности кода строка начинающаяся с Enumerable.Combine( и Path.Combina( сильно вредит. Строка должна начинаться со смысловой нагрузки сужающей контекст, а не с глобального метода понять который мы можем только прочитав его аргументы.
G>>Начало выражения Enumerable.Combine( не сужает контекст выбора и для понимания и для подсказки автовыбора, а начало выражения с первого аргумента сужает. Так что тут ты объективно не прав.

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


S>не понял в чем я не прав. Path.Combine прекрасно сужает контекст. Что бы понять, что он делает, вовсе не обязательно читать аргументы.
S>Автовыбор меня мало беспокоит, т.к. я код больше читаю чем пишу.
S>Повторюсь. Путь.Комбинируйся с другим путем для меня — порно. Так же как и Путь.КопируйФайл(другойПуть). Так же как и объект.Сравнись(другойОбъект).
S>Вот путь / другойПуть — это хорошо. Но ради этого не стоит писать столько кода. Префиксная запись не сильно хуже в данном случае.

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

G>Часто говорят "сложить два плюс три", что как бэ намекает.
Я такое слышу не часто. Либо "два плюс три", либо "сложить 2 и 3".

G>Зачем мне отвлекаться? Это у вас в голове префиксная нотация сидит. Она не является общепринятой именно по тем причинам что я указал, начинается с знака операции, а не аргумента, и сложнее для чтения и понимания результата, акцентирует на операции. Общепринятая же форма 5 − (6 * 7). А есть еще такая * − 5 6 7. Если тебе нравится последняя форма записи, это не значит учто она должна быть у всех, большинство предпочитает инфиксную.
G>Префиксная запись имеет смысл только в случае когда операция для понимания важнее чем аргумент и она одна в строке.
Предлагаю разделять общепринятую инфиксную запись арифметических операций и общепринятую префиксную запись вызова функций. Все-таки арифметика файловых путей не вполне очевидна и не вполне очевидно использование операции деления для этой арифметики. А Path.Combine как бы намекает.
Запись "var p = p1 / p2" вне контекста вообще теряет смысл комбинирования путей.

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

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

G>Path.Combine не сужает контекст и не дает точку выбора.
Можно подробнее?
G>Мы оперируем аргументами, а не операциями, поскольку вариативность аргументов больше вариативности операций.
Мы — это кто? Я вполне себе могу оперировать операциями и в том числе операциями в качестве аргументов других операций.
G>Префиксная форма записи понимается только по прочтению всего выражения совокупно, а инфиксная по прочтению части выражения.
Откуда это следует?
G>А самой удобной кому-то может показаться вообще постфиксная в которой операции вообще в конце стоят.
Кому-то может.
G>Поняли аргументы и только после этого применяем операции. А вы выбрали вообще самый непопулярный и неудобный вариант, префиксную. И привыкли к ней. Ну пусть, но только отстаивать свою дремучесть не нужно.
Многие привыкли к префиксной. Ты же не пишешь 5 max 3. Или пишешь? Если пишешь max(5, 3) — значит так же дремуч. Или может твоя дремучесть избирательна? Ведь суть + и max как операций не сильно отличается. Обе принимают аргументы и возвращают результат. Так почему + используют инфиксно, а max — префиксно?

S>Запись "var p = p1 / p2" вне контекста вообще теряет смысл комбинирования путей.

Вообще-то вне контекста любое такое выражение теряет смысл.
С другой стороны, "var i = i1 + i2" это вообще сложение или конкатенация? По правильному сложение, ибо i это должно быть целое. А "var p = p1 / p2" p это должна быть адресная арифметика, в которое вроде бы / нету, что дает нам правильное направление понимания. Так что опять промахнулся ты.

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

S>>Запись "var p = p1 / p2" вне контекста вообще теряет смысл комбинирования путей.

G>Вообще-то вне контекста любое такое выражение теряет смысл.
G>С другой стороны, "var i = i1 + i2" это вообще сложение или конкатенация? По правильному сложение, ибо i это должно быть целое. А "var p = p1 / p2" p это должна быть адресная арифметика, в которое вроде бы / нету, что дает нам правильное направление понимания. Так что опять промахнулся ты.
Это ты промахнулся с теорией о том что прочтение аргумента сужает контекст. Вот ты прочитал аргумент, а контекст угадываешь. В то время как String.Concat(i1, i2) снимает вообще все вопросы.

G>>Path.Combine не сужает контекст и не дает точку выбора.
S>Можно подробнее?

Ну вот написал ты Path.Combine(, что тебе дает редактор в качестве подсказки для выбора? Ага, варианты вызова этого Path.Combine(, а зачем оно тут надо? Операция простая, зачем тут подсказка что у комбине может быть три строковых аргумента или четыре?
Ну вот написал ты Path.Combine(, что это дает для поинимания алгоритма? А ничего. Мы оперируем сущностями, операции суть вспомогательные вещи. В общем случае важнее ЧТО, а не КАК.

Абстрактные примеры с алгеброй (2 + 3) тут не очень подходят, потому что сказав

2

мы тоже не сужаем контекст.
А если ты написал именованный аргумент

temp_path

У тебя есть сужение контекста на уровне возможного применения операции, -> появляется контекстная подсказка автовыбора операции.
У тебя есть сужение контекста на проблемном уровне для понимания, ты выбрал какой-то конкретный фолдер, файловый путь.
Появляются ват такие возможности оптимизации кода:



G>>Мы оперируем аргументами, а не операциями, поскольку вариативность аргументов больше вариативности операций.
S>Мы — это кто? Я вполне себе могу оперировать операциями и в том числе операциями в качестве аргументов других операций.

Пример выше

G>>Префиксная форма записи понимается только по прочтению всего выражения совокупно, а инфиксная по прочтению части выражения.
S>Откуда это следует?

То же пример

G>>Поняли аргументы и только после этого применяем операции. А вы выбрали вообще самый непопулярный и неудобный вариант, префиксную. И привыкли к ней. Ну пусть, но только отстаивать свою дремучесть не нужно.
S>Многие привыкли к префиксной. Ты же не пишешь 5 max 3. Или пишешь? Если пишешь max(5, 3) — значит так же дремуч. Или может твоя дремучесть избирательна? Ведь суть + и max как операций не сильно отличается. Обе принимают аргументы и возвращают результат. Так почему + используют инфиксно, а max — префиксно?

max на самом деле это операция подытоживания, агрегирования результата выполнения более простых рядовых операций или перечисления. И в этом смысле она заслужила один балл для продвижения (из инфикса в префикс или постфикс), как чуть-чуть нерядовая. Path.Combine же самая рядовая операция в операциях с файловым путем и ее место в инфиксе.

S>>>Запись "var p = p1 / p2" вне контекста вообще теряет смысл комбинирования путей.

G>>Вообще-то вне контекста любое такое выражение теряет смысл.
G>>С другой стороны, "var i = i1 + i2" это вообще сложение или конкатенация? По правильному сложение, ибо i это должно быть целое. А "var p = p1 / p2" p это должна быть адресная арифметика, в которое вроде бы / нету, что дает нам правильное направление понимания. Так что опять промахнулся ты.
S>Это ты промахнулся с теорией о том что прочтение аргумента сужает контекст. Вот ты прочитал аргумент, а контекст угадываешь. В то время как String.Concat(i1, i2) снимает вообще все вопросы.

Так ведь пример получился хороший. В итоге я буду писать var s = s1 + s2; (и var p = p1 / p2. А ты будешь писать var i = String.Concat(i1, i2); и никто тебя не переубедит писать по другому.

Что меня удивляет, так это почему меня местные бандерлоги не заминусовали? Вроде бы пишу разумные вещи. Загадка.

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

G>>>Path.Combine не сужает контекст и не дает точку выбора.
S>>Можно подробнее?

G>Ну вот написал ты Path.Combine(, что тебе дает редактор в качестве подсказки для выбора? Ага, варианты вызова этого Path.Combine(, а зачем оно тут надо? Операция простая, зачем тут подсказка что у комбине может быть три строковых аргумента или четыре?
G>Ну вот написал ты Path.Combine(, что это дает для поинимания алгоритма? А ничего. Мы оперируем сущностями, операции суть вспомогательные вещи. В общем случае важнее ЧТО, а не КАК.
И Path.Combine и "/" одинакого подробно говорят о том, КАК. Точнее одинакого не говорят. А о том, ЧТО именно нужно сделать с аргументами, больше говорит Path.Combine.
Да, я пишу не для редактора, а для себя. Потому, даст он мне подсказку, или нет — это вопрос десятый. Кстати, по поводу "/" не даст.

G>Абстрактные примеры с алгеброй (2 + 3) тут не очень подходят, потому что сказав

G>2

G>мы тоже не сужаем контекст.
G>А если ты написал именованный аргумент

G>temp_path

G>У тебя есть сужение контекста на уровне возможного применения операции, -> появляется контекстная подсказка автовыбора операции.
и что, -> вывалит операцию + для целого числа?
G>У тебя есть сужение контекста на проблемном уровне для понимания, ты выбрал какой-то конкретный фолдер, файловый путь.
G>Появляются ват такие возможности оптимизации кода:
Я сужаю контекст другим способом. Я указываю что я буду именно копировать, а потом, по каким путям.

S>>Мы — это кто? Я вполне себе могу оперировать операциями и в том числе операциями в качестве аргументов других операций.

G>Пример выше
Не обнаружил

G>>>Префиксная форма записи понимается только по прочтению всего выражения совокупно, а инфиксная по прочтению части выражения.
S>>Откуда это следует?

G>То же пример
не пойму, о каком примере речь.

S>>Многие привыкли к префиксной. Ты же не пишешь 5 max 3. Или пишешь? Если пишешь max(5, 3) — значит так же дремуч. Или может твоя дремучесть избирательна? Ведь суть + и max как операций не сильно отличается. Обе принимают аргументы и возвращают результат. Так почему + используют инфиксно, а max — префиксно?

G>max на самом деле это операция подытоживания, агрегирования результата выполнения более простых рядовых операций или перечисления.
"+" — такая же операция подытоживания и агрегирования, как и max
G>И в этом смысле она заслужила один балл для продвижения (из инфикса в префикс или постфикс), как чуть-чуть нерядовая. Path.Combine же самая рядовая операция в операциях с файловым путем и ее место в инфиксе.
Так дело в "рядовости"? Ну я же говорил, избирательная "дремучесть". Теперь вижу что избирательность основана на рядовости. И видимо, по-твоему max это не рядовая операция для аргументов, а копирование файлов — рядовая для путей. Интересно

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

S>>>>Запись "var p = p1 / p2" вне контекста вообще теряет смысл комбинирования путей.

G>>>Вообще-то вне контекста любое такое выражение теряет смысл.
G>>>С другой стороны, "var i = i1 + i2" это вообще сложение или конкатенация? По правильному сложение, ибо i это должно быть целое. А "var p = p1 / p2" p это должна быть адресная арифметика, в которое вроде бы / нету, что дает нам правильное направление понимания. Так что опять промахнулся ты.
S>>Это ты промахнулся с теорией о том что прочтение аргумента сужает контекст. Вот ты прочитал аргумент, а контекст угадываешь. В то время как String.Concat(i1, i2) снимает вообще все вопросы.

G>Так ведь пример получился хороший. В итоге я буду писать var s = s1 + s2; (и var p = p1 / p2. А ты будешь писать var i = String.Concat(i1, i2); и никто тебя не переубедит писать по другому.
Ну почему же, обычно я конкатенирую строки через "+" (когда их не сильно много). Я просто указал на то что String.Concat убирает вопросы, которые может оставить "+".

S>Так дело в "рядовости"? Ну я же говорил, избирательная "дремучесть". Теперь вижу что избирательность основана на рядовости. И видимо, по-твоему max это не рядовая операция для аргументов, а копирование файлов — рядовая для путей. Интересно

Насчет файловых операций неоднозначно. Где-то удобнее написать так, что допустимо в моей нотации:

File.Copy(path1 / filename1, path2 / filename2);

а где-то так:

(path1 / filename1) .Rename(filename2);
или
file1.Rename(filename2);

а не

File.Move(path1 / filename1, path2 / filename2);

G>>Так ведь пример получился хороший. В итоге я буду писать var s = s1 + s2; (и var p = p1 / p2. А ты будешь писать var i = String.Concat(i1, i2); и никто тебя не переубедит писать по другому.
S>Ну почему же, обычно я конкатенирую строки через "+" (когда их не сильно много). Я просто указал на то что String.Concat убирает вопросы, которые может оставить "+".


А оно надо убирать какие-то неизвестные мне вопросы через String.Concat()? Я не помню ни одного случая необходимости String.Concat(). Оно несомненно где-то было, но как-то обходился без этого. Хотя разработчики языка конечно могли пойти по твоему пути и убрать это некошерные плюсики для конкатенации строк.

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

S>>Так дело в "рядовости"? Ну я же говорил, избирательная "дремучесть". Теперь вижу что избирательность основана на рядовости. И видимо, по-твоему max это не рядовая операция для аргументов, а копирование файлов — рядовая для путей. Интересно

G>Насчет файловых операций неоднозначно. Где-то удобнее написать так, что допустимо в моей нотации:

G>File.Copy(path1 / filename1, path2 / filename2);

G>а где-то так:

G>(path1 / filename1) .Rename(filename2);
G>или
G>file1.Rename(filename2);

G>а не

G>File.Move(path1 / filename1, path2 / filename2);

Вопрос не удобства, а семантики. В одном случае идет обращение к методам, выполняющим файловые операции. В другом случае обращение происходит к аргументу (пути) о том что надов выполнить копирование файла.
path.Copy(..) примерно так же как и str.SendEmail(sender).

По поводу деления путей: Операция деления не определена ни для строк, ни для путей. Ты пользуешься тем, что слэш является альтернативным разделителем. Но семантика-то у операции "слэш" — именно деление. Можешь обвинять меня в дремучести, но это придумал не я.
Можешь использовать слэш для комбинирования путей, я могу использовать слэш для комбинирования путей, но обвинять людей в дремучести только потому что они не хотят использовать слэш для комбинирования путей — это немного за рамками.

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

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

G>>>Так ведь пример получился хороший. В итоге я буду писать var s = s1 + s2; (и var p = p1 / p2. А ты будешь писать var i = String.Concat(i1, i2); и никто тебя не переубедит писать по другому.
S>>Ну почему же, обычно я конкатенирую строки через "+" (когда их не сильно много). Я просто указал на то что String.Concat убирает вопросы, которые может оставить "+".

G>А оно надо убирать какие-то неизвестные мне вопросы через String.Concat()? Я не помню ни одного случая необходимости String.Concat(). Оно несомненно где-то было, но как-то обходился без этого. Хотя разработчики языка конечно могли пойти по твоему пути и убрать это некошерные плюсики для конкатенации строк.
И еще раз другими словами. Я не утверждаю что оно кому-то надо. Я показываю разницу в понимании выражения с String.Concat и выражении с "+". И это противоречит твоим утверждениям о том что для того что бы понять суть выражения в префиксной нотации, нужно прочитать аргументы. Ровно наоборот. Что бы понять что происходит между s1 и s2, надо не только прочитать аргументы, а и определить типы выражений в аргументах. Только тогда можно будет с уверенностью говорить о том, что именно происходит под знаком "+". В то время как String.Concat указывает на это явно.

G>>>>Так ведь пример получился хороший. В итоге я буду писать var s = s1 + s2; (и var p = p1 / p2. А ты будешь писать var i = String.Concat(i1, i2); и никто тебя не переубедит писать по другому.
S>>>Ну почему же, обычно я конкатенирую строки через "+" (когда их не сильно много). Я просто указал на то что String.Concat убирает вопросы, которые может оставить "+".

G>>А оно надо убирать какие-то неизвестные мне вопросы через String.Concat()? Я не помню ни одного случая необходимости String.Concat(). Оно несомненно где-то было, но как-то обходился без этого. Хотя разработчики языка конечно могли пойти по твоему пути и убрать это некошерные плюсики для конкатенации строк.
S>И еще раз другими словами. Я не утверждаю что оно кому-то надо. Я показываю разницу в понимании выражения с String.Concat и выражении с "+". И это противоречит твоим утверждениям о том что для того что бы понять суть выражения в префиксной нотации, нужно прочитать аргументы. Ровно наоборот.

Да с какого? String.Concat( без аргументов ты не можешь прочитать, ибо это знание не о том что ты пишешь не о твоем коде совсем.

S>Что бы понять что происходит между s1 и s2, надо не только прочитать аргументы, а и определить типы выражений в аргументах. Только тогда можно будет с уверенностью говорить о том, что именно происходит под знаком "+". В то время как String.Concat указывает на это явно.

String.Concat без аргументов указывает на String.Concat, то есть фактически ни на что не указывает и никому никогда не нужно. Поэтому от него отказались в пользу +. Знание которое содержится в String.Concat не нужно тащить в код, так же как и миллион других вещей, знание о регистрах процессора или времени выполнения. Потому что важна здесь не операция, она может быть только одна, а важны аргументы.

s1 уже указывает на твою предметную область

s1 + уточняет
s1 + s2 понимаемо
s1 + s2 + s3 читаем дольше сохраняя контекст

твой вариант

File.Move( — ???
File.Move(Path.Combine( — ???
File.Move(Path.Combine(path1 — Петрович???
File.Move(Path.Combine(path1, file1) — Петровича чемодан, что с ним? А, вспомнил, куда везем?
File.Move(Path.Combine(path1, file1), path3); — а-а-а, так вот оно как...

мой вариант

path1 — Петрович???
path1 / file1 — Петровича чемодан
(path1 / file1) .FileMove( — куда везем?
(path1 / file1) .FileMove(path3); — Ну дык эта понятно...

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

S>>И еще раз другими словами. Я не утверждаю что оно кому-то надо. Я показываю разницу в понимании выражения с String.Concat и выражении с "+". И это противоречит твоим утверждениям о том что для того что бы понять суть выражения в префиксной нотации, нужно прочитать аргументы. Ровно наоборот.

G>Да с какого? String.Concat( без аргументов ты не можешь прочитать, ибо это знание не о том что ты пишешь не о твоем коде совсем.
Как это не могу прочитать? Могу. И если String.Concat написано в моем коде, то то что я прочитаю будет знанием о моем коде.

S>>Что бы понять что происходит между s1 и s2, надо не только прочитать аргументы, а и определить типы выражений в аргументах. Только тогда можно будет с уверенностью говорить о том, что именно происходит под знаком "+". В то время как String.Concat указывает на это явно.

G>String.Concat без аргументов указывает на String.Concat, то есть фактически ни на что не указывает и никому никогда не нужно. Поэтому от него отказались в пользу +. Знание которое содержится в String.Concat не нужно тащить в код, так же как и миллион других вещей, знание о регистрах процессора или времени выполнения. Потому что важна здесь не операция, она может быть только одна, а важны аргументы.
Как это операция может быть только одна? Посмотри сколько операций над строками.
А + победил Concat по паре простых причин — он значительно короче и понимается компилятором.

G>s1 уже указывает на твою предметную область
не указывает.

G>s1 + уточняет
G>s1 + s2 понимаемо
G>s1 + s2 + s3 читаем дольше сохраняя контекст

G>твой вариант

G>File.Move( — ???
Уже понятно, что перемещаем файл. Если ты этого не понимаешь на этой стадии, то мне жаль.
G>File.Move(Path.Combine( — ???
G>File.Move(Path.Combine(path1 — Петрович???
G>File.Move(Path.Combine(path1, file1) — Петровича чемодан, что с ним? А, вспомнил, куда везем?
G>File.Move(Path.Combine(path1, file1), path3); — а-а-а, так вот оно как...


G>мой вариант

G>path1 — Петрович???
G>path1 / file1 — Петровича чемодан
G>(path1 / file1) .FileMove( — куда везем?
G>(path1 / file1) .FileMove(path3); — Ну дык эта понятно...
Может тебе эта, так еще понятнее было бы?
(стакан / чай).Мешать(ложка)

S>(стакан / чай).Мешать(ложка)

Твой вариант будет

Движения.Мешать(Операции.Налить(стакан, чай), ложка)

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

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

S>>(стакан / чай).Мешать(ложка)

G>Твой вариант будет

G>Движения.Мешать(Операции.Налить(стакан, чай), ложка)

G>Где внимание акцентировано на операциях. В итоге получаем театральную чайную церемонию и чай из пакетика. Если нам важна церемония, то это хорошо, если важен чай, то это плохо. Если важен чай, то его и нужно ставить на первое место.
Удивительно что тебя не смутил тип результата комбинирования стакана и чая. Главное поставить вперед перед "мешать" этакое сужение контекста.

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

G>Это враппер для System.IO.Path, File, Directory, их полный 100% порт в объект PathInfo и дополнительные плюшки.

Ненужно абсолютно. Сэкономьте силы для более полезных вещей.

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

S>Уже указывал на несоответствие требований к реализации 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.

Собственно еще тот факт что твой путь может быть равен некоторй строке тоже портит малину, ведь строка не будет считать себя равной твоему пути.

M>Как к каталогу можно применять ФилеЦопи??

Вот да, путь он такой, список файлов это неотъемлемое его свойство, и у пути к каталогу и у пути к файлу. И соответственно теоретически для пути будут доступны групповые операции и операции над множествами, всякие богомерзкие enumerable, linq и все такое, вот гадость-то прости хоспади. Гораздо проще один файл прибитый гвоздями, согласен.


M>Вот эта ментальная закавыка говорит только об одном — отстойном проектировании отношений: смешали в кучу коней, людей, на выходе — Бородино, млин!

Вся эта ментальная закавыка возникла у тебя. А у меня это много лет пользуется без ментальных закавык.


M>Вобщем, кому-то чешется наприменять всякой ерундистики безо всякого вдумчивого проектирования и учёта стандартных соглашений. ФП — это пузырь, запишите и не пихайте его во невпихуемое.


Че к чему? Оно работает и удобно. Чего ты тут не смог впихнуть?

S>>Так же финальный "return 0" в CompareTo означает что объект будет равен всему, что не PathInfo и не строка. Т.е. равен 1-е, списку, словарю и т.п. А это ломает симметричность, т.к. вряд ли все остальные объекты будут думать так же по поводу твоего PathInfo.

S>Собственно еще тот факт что твой путь может быть равен некоторй строке тоже портит малину, ведь строка не будет считать себя равной твоему пути.


А ты попробуй предположить в каких ситуациях такой вызов возникнет? А вот то-то и оно. Синтаксически строка и не вызовет никогда этот метод для сравнения с собой, ибо. А вот сравнивать мой объект со строкой я могу и только в этом случае вызывается этот метод с таким параметром. Хотя можно и вырезать, для простоты и понятности, не определилися я еще, нужно практику применения проверить.

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

Идея интересная.
Но так и не ясно чем ваш код лучше альтернатив которые вы же и привели.


Насчет 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 путя после выполнения сортировки может быть не отсортирован.
Если ситуация с поиском строки в массиве путей сомнительна, то это конкретный ахтунг.
Так же будет сбоить проверка наличия пустого пути в хэштаблице.

Тогда такой вопрос уточняющий: ты предлагаешь убрать вот это соглашение об эквивалентности двух пустых объектов:
Empty == Empty ?

Но это приведет к необходимости создавать некий аналог string.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 с решением несуществующей проблемы и заявляет:

"Это враппер... и дополнительные плюшки.", "Прошу посмотреть и сказать мне, нужно ли это допиливать до совершенства или забросить куда подальше."

Начинаются терпеливые объяснения почему код выглядит алогичным и почему этот проект надо, КАК И ПРЕДЛАГАЛОСЬ, "забросить куда подальше." Вместо восприятия аргументов, отважный Наполеон начинает усираться с защитой своей кривой логики, прикрываясь пузырём функциональщины и типа "экономии символов". Может, пора уже остыть, товарищ? Вас никто здесь за гения не держит, можно расслабиться — выкиньте свой враппер и возьмитесь за задачи, которые действительно могли бы быть полезны. Например, диалог открытия файла в 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) как раз.

S>Твой код? Если да, то будут ли два путя со свойством Empty эквивалентны?

Теперь увидел. При сортировке нетипизированной коллекции этот баг мог проявляться, теперь я понял твой пример. Исправил.

M>"Это враппер... и дополнительные плюшки.", "Прошу посмотреть и сказать мне, нужно ли это допиливать до совершенства или забросить куда подальше."

M>Начинаются терпеливые объяснения почему код выглядит алогичным и почему этот проект надо, КАК И ПРЕДЛАГАЛОСЬ, "забросить куда подальше." Вместо восприятия аргументов, отважный Наполеон начинает усираться с защитой своей кривой логики, прикрываясь пузырём функциональщины и типа "экономии символов". Может, пора уже остыть, товарищ? Вас никто здесь за гения не держит, можно расслабиться — выкиньте свой враппер и возьмитесь за задачи, которые действительно могли бы быть полезны. Например, диалог открытия файла в WPF — его до сих пор нет.


Успокойся. Я же не решаю задачу, новую, я всего-лишь оформляю какой-то рабочий код, который используется. Диалога открытия файла в WPF у меня нет готового, извини

G>>В плане синтаксиса просто получается более чистый и компактный код, за счет того что выражение операции или команды можно написать как классически File.Copy(), (так и после длинного селектора).FileCopy()
_NN>Кроме компактности должна быть и выразительность.
_NN>А делать обертки для File.Read в виде метода ReadFile как-то смшено.

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


_NN>>>Некоторые замечания:
_NN>>>Файл на 3000 строк ? Может стоить разделить ?

G>>Модуль-то? Идея в том что его можно скопировать и просто вставить в проект, одним файлом. Для упрощения его использования. Если будет несколько какой-то может потеряться.
_NN>Для упрощения использования есть проект или пакет NuGet , а сколько там файлов не так важно.

А сейчас размер модуля как-то мешает? Я просто не понимаю. Фактически один класс, остальные маленькие.


G>>Поскольку это сравнение двух путей, то сравнение идет начиная с корневого каталога и дальше вниз и если на каком-то уровне неравенство это и будет результат. Это общее правило сравнения файловых путей. z:\a.txt > a:\z.txt потому что z: > a: как-то так.
_NN>На мой взгляд это не нужно реализовывать в самом PathInfo.
_NN>Пусть будет PathInfoComparer, PathInfoExpandedPathComparer , ведь есть несколько способ сравнивать и неясно что из этого лучше.

Я постараюсь найти в инете какие-нибудь примеры.


G>>У шарпа немного операторов которые можно перегрузить и они имеют фиксированный порядок выполнения. "|" тут просто не получится, будут возникать синтаксические ошибки в сложных выражениях.
_NN>А с '&' не будет ? У вас есть пример ?

Не помню. Но изначально я сделал именно |, а потом пришлось сменить из за ошибок.


_NN>Разницы между a & "*.tmp" и a.Files("*.tmp") не так много, а код понятней.


Это аналоги.

var x = a / b & c; тут лучше оператором, аналог будет var x = (a/b).Files(c);



_NN>Вот метод 'Bulk' не нужно добавлять в PathInfo.

Bulk в PathList. Он нужен для работы с селекторами, потому что там нельзя применить агрегатабл. Но их еще нет в этом объекте, я их еще не перетаскивал.


_NN>Это 100% экономия Решарпер сам вставит за вас этот код не напрягаясь.

А его не нужно вставлять. Он как бы и не нужен.


_NN>Зачем наследоваться от PathInfo ?
_NN>Я бы его сделал запечатанным (sealed) как раз. не нужно добавлять в PathInfo.


Ну как минимум у нас есть ShellPathInfo который наследуется от этого объекта, поэтому запечатать не получится.

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

G>А сейчас размер модуля как-то мешает? Я просто не понимаю. Фактически один класс, остальные маленькие.
Мешает что файл большой и разобраться другим в нем сложно.

G>Не помню. Но изначально я сделал именно |, а потом пришлось сменить из за ошибок.
Поэтому и лучше метод =)

G>var x = a / b & c; тут лучше оператором, аналог будет var x = (a/b).Files(c);
Вряд ли кто-то напишет a / b & c потому как помнить приоритеты это нелегко, скорее будет (a / b) & c , что не так далеко уходит от (a / b).Files(c);


G>Ну как минимум у нас есть ShellPathInfo который наследуется от этого объекта, поэтому запечатать не получится.
А зачем ему наследование ?

G>>А сейчас размер модуля как-то мешает? Я просто не понимаю. Фактически один класс, остальные маленькие.
_NN>Мешает что файл большой и разобраться другим в нем сложно.

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


G>>Не помню. Но изначально я сделал именно |, а потом пришлось сменить из за ошибок.
_NN>Поэтому и лучше метод =)

G>>var x = a / b & c; тут лучше оператором, аналог будет var x = (a/b).Files(c);
_NN>Вряд ли кто-то напишет a / b & c потому как помнить приоритеты это нелегко, скорее будет (a / b) & c , что не так далеко уходит от (a / b).Files(c);

Запомню.


G>>Ну как минимум у нас есть ShellPathInfo который наследуется от этого объекта, поэтому запечатать не получится.
_NN>А зачем ему наследование ?


Потому что несмотря на то что шелл-путь другой и у него другая иерархия, по большей части он отображается на обычную файловую систему и можно использовать этот функционал. Ну и удобно реализовывать такие вещи как ShellLink наследуясь от ShellPathInfo в свою очередь, а суть та же — файл, методы PathInfo переиспользуются для других сущностей. Из понятия "Файл" много чего растет.

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


G>Потому что несмотря на то что шелл-путь другой и у него другая иерархия, по большей части он отображается на обычную файловую систему и можно использовать этот функционал. Ну и удобно реализовывать такие вещи как ShellLink наследуясь от ShellPathInfo в свою очередь, а суть та же — файл, методы PathInfo переиспользуются для других сущностей. Из понятия "Файл" много чего растет.

Суть та же не означает автоматически, что нужно наследовать.
Если хотите наследование, то объявите интерфейс IPathInfo и от него наследуйте сколько хотите.

Во первых это уменьшает связанность , а во вторых упрощает написание тестов.

_NN>Суть та же не означает автоматически, что нужно наследовать.
_NN>Если хотите наследование, то объявите интерфейс IPathInfo и от него наследуйте сколько хотите.

Не совсем понятно зачем бы понадобился такой интерфейс, кроме как в унаследованных от PathInfo реализациях.

_NN>Во первых это уменьшает связанность , а во вторых упрощает написание тестов.

Да как бы не мешает написанию тестов, а связанность тут экономит время. Вот я внес кучу изменений в PathInfo, автоматически получил их в ShellPathInfo и ни одной ошибки или несоответствия. Если бы не было наследования, я бы сейчас получил бы различия в этих двух классах и копался бы для того что бы оно скомпилировалось с унаследованным интерфейсом. То есть затраты времени выросли бы раза в два. Я же не бригада, а человек.

M> Например, диалог открытия файла в WPF — его до сих пор нет.

Кстати, а что там с диалогом открытия файлов? В каком смысле его нет? Или это стеб был?

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

M>> Например, диалог открытия файла в WPF — его до сих пор нет.

G>Кстати, а что там с диалогом открытия файлов? В каком смысле его нет?

В физическом — его для WPF вообще нет. Приходится использовать платформо-зависимый, хардкоженый костыль из Win32.

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

M>В физическом — его для WPF вообще нет. Приходится использовать платформо-зависимый, хардкоженый костыль из Win32.

Как буд-то ВПФ умеет исполняться на чем-то другом...

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

M>>... хардкоженый костыль из Win32.
H>Как буд-то ВПФ умеет исполняться на чем-то другом...

Согласен, на данный момент альтернатив нет. Но кто знает, чо там выкатят завтра! Идея-то правильная, а значит у неё будут новые реинкарнации.
Никто ж не знал, например, что появится Xamarin!
Кстати, WPF — он только от мелкомягких такой сложный, его ж можно урезать и тогда будет легче реализовывать.

M>>>... хардкоженый костыль из Win32.
H>>Как буд-то ВПФ умеет исполняться на чем-то другом...

M>Согласен, на данный момент альтернатив нет. Но кто знает, чо там выкатят завтра! Идея-то правильная, а значит у неё будут новые реинкарнации.
M>Никто ж не знал, например, что появится Xamarin!
M>Кстати, WPF — он только от мелкомягких такой сложный, его ж можно урезать и тогда будет легче реализовывать.


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

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

G>Что-то я не совсем понял. Так ты предлагаешь запилить диалог в надежде что мелкомягкие выкатят что-то в чем этот диалог понадобится?

Не распарсил вопрос.