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);
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 не нужно тащить в код, так же как и миллион других вещей, знание о регистрах процессора или времени выполнения. Потому что важна здесь не операция, она может быть только одна, а важны аргументы.
File.Move( — ???
File.Move(Path.Combine( — ???
File.Move(Path.Combine(path1 — Петрович???
File.Move(Path.Combine(path1, file1) — Петровича чемодан, что с ним? А, вспомнил, куда везем?
File.Move(Path.Combine(path1, file1), 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); — Ну дык эта понятно...
Может тебе эта, так еще понятнее было бы?
(стакан / чай).Мешать(ложка)
Где внимание акцентировано на операциях. В итоге получаем театральную чайную церемонию и чай из пакетика. Если нам важна церемония, то это хорошо, если важен чай, то это плохо. Если важен чай, то его и нужно ставить на первое место.
Здравствуйте, grosborn, Вы писали:
S>>(стакан / чай).Мешать(ложка)
G>Твой вариант будет
G>Движения.Мешать(Операции.Налить(стакан, чай), ложка)
G>Где внимание акцентировано на операциях. В итоге получаем театральную чайную церемонию и чай из пакетика. Если нам важна церемония, то это хорошо, если важен чай, то это плохо. Если важен чай, то его и нужно ставить на первое место.
Удивительно что тебя не смутил тип результата комбинирования стакана и чая. Главное поставить вперед перед "мешать" этакое сужение контекста.
. А ты будешь писать var i = String.Concat(i1, i2); и никто тебя не переубедит писать по другому.
