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

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

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

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

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

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