Comments 47
Кортежи — это очень спорная фича, особенно для языка со статической типизацией. Если раньше не-очень-хорошим-программистам приходилось напрячься, чтобы вводя новую сущность в коде дать ей внятное название, теперь они вообще напрягаться не будут прикрываясь «использованием языка на всю катушку».
Это как раз хреновый пример, который воспринимается на порядок хуже, чем длинное скучное:
list.Add("John Doe", 66); // Такое добавление данных в лист не может не радовать
Это как раз хреновый пример, который воспринимается на порядок хуже, чем длинное скучное:
list.Add(new Person
{
Name = "John Doe",
Age = 66
});
Кортежи — это одна из тех естественных вещей, которая была неочевидна (или недоступна в явном виде) в течение очень долгого времени, и только недавно стала проникать в мейнстрим. В общем, кортеж — это группа имен времени компиляции и не более того. Список аргументов функции — кортеж. Список инициализации в фигурных скобках — это тоже кортеж. Даже список полей и методов класса тоже можно рассматривать как кортеж (хотя и не кортеж объектов, а скорее чистый кортеж имен — это уже к метапрограммированию). В идеале, это способ группировки чего угодно на этапе компиляции — и в общем это более фундаментально чем структура (которая по сути лишь кортеж в обертке типа). И множественный возврат из функции — лишь самое очевидное применение. Как насчет групповых или множественных операций?
Хотя и это мелочи. Думаю, со временем ситуация с кортежами прояснится и раскроется их мощь, а то многие думают что это недоструктура или даже недосписок как в питоне.
(i, j, k) = (a, b, c);
(i, j, k) += 100;
Хотя и это мелочи. Думаю, со временем ситуация с кортежами прояснится и раскроется их мощь, а то многие думают что это недоструктура или даже недосписок как в питоне.
Вы бы лучше пример кода привели, чтобы показать где эта конструкция выигрывает по сравнению с явным типом. Что такое кортеж — вполне понятно. Также понятно какие проблемы будут возникать при его использовании. Что непонятно — какие проблемы он решает.
Тип номинативно-типизирован, кортеж — структурно-типизирован. Это разные вещи с разными областям применения. Если вам нужна функция, принимающая два параметра — вы пишете функцию с двумя аргументами, а не функцию, принимающую тип с двумя полями. Также и здесь. Бывает, когда нужно вернуть из функции объект (как единое целое) — в этом случае объявляется структура; а если нужно вернуть просто два значения, никак не связанных между собой — применяется кортеж и множественный возврат из функции.
если нужно вернуть просто два значения, никак не связанных между собой
Если возникает необходимость вернуть 2 значения, никак не связанных между собой, стоит пересмотреть ответственности, возложенные на метод. Предложите пример такого метода — интересно чем вы будете руководствоваться придумывая для него имя.
Магазину «Котлеты и Ноутбуки» срочно требуется определиться
Таких котлет и ноутбуков — вагон и тележка.
Обычай предписывает использовать для этого out-параметры
В С++ есть функции, возвращающие пару — например, итератор и флажок при вставке в set.
Предложите, как пересмотреть ответственности для них.
Обычай предписывает использовать для этого out-параметры
Cutlet GetCutletAndNotebook(out Notebook nb)
В С++ есть функции, возвращающие пару — например, итератор и флажок при вставке в set.
Предложите, как пересмотреть ответственности для них.
Таких котлет и ноутбуков — вагон и тележка.
Обычай предписывает использовать для этого out-параметры
out-параметры — это минорная фича, необходимость в которой возникает крайне редко. Я не знаком с историей её возникновения, но предположу, что на 90% мотивация была — байндинги для сишного кода. Очень многие функции WinAPI возвращают «полезный результат» через параметр, а возвращаемое значение используют для кода возврата. Это традиция из культуры C — там нет исключений, поэтому возникает та самая интересная ситуация когда нужно и код возврата сообщить, и полезные данные вернуть. В Java, например, out-параметров вообще нет — проблем с этим не возникает.
В С++ есть функции, возвращающие пару — например, итератор и флажок при вставке в set.
Предложите, как пересмотреть ответственности для них.
У стандартной библиотеки C++ своя уникально-экзотическая философия из которой органично вытекает этот неповторимый извращённый дизайн. Во многих других мейнстримных языках аналогичный метод возвращает bool и сложностей ни у кого не возникает.
Зачем предлагать, когда уже и так есть в самом .NET:
TryParse и его разновидности.
TryParse и его разновидности.
А чем Tuple<> не угодил?
github.com/dotnet/roslyn/issues/347 — см раздел background
(i, j, k) += 100;
Тут больше подходит не кортеж, а
IEnumerable<T>. В кортеже все типы могут быть разные и абсолютно непонятно, что тогда должен делать такой оператор.
В отсутствии кортежей есть один недостаток. Вот пишешь ты метод, в нем юзаешь анонимный тип. А потом хочешь сделать extract to method — и все, все плюшки закончились. Нужно вводить новый класс, переопределять операции == (хотя можно делать nullable structures, там вроде это автоматом идет), а это на порядки больше времени/места занимает.
В итоге у вас:
1) Либо один большой говнометод
2) Много непонятных data-классов, которые нужны только в пределах двух-трех методов
3) Либо код будет содержать Tuple/KeyValuePair, что вообще читабельности не добавляет.
И кортежи решают проблему — у вас появляются анонимные типы (статически типизированные и с адекватными именами свойств), которые легко шарятся между тремя методами. Т.е. можно писать короткие методы (держа каждый метод на едином уровне абстракции) и не писать лишнего говнокода. На всякий случай: количества смысла и адекватности на одну строку кода повышается.
Не, можно конечно юзать это и во вред проекту. Но в C# есть более опасная фича в виде dynamic, а её никто не спешит юзать без реальной нужды.
Также вместе с кортежами должны идти pattern matching/destructuring. Это по сути возможность написать foreach ((var id, var name) in dictionary)
В итоге у вас:
1) Либо один большой говнометод
2) Много непонятных data-классов, которые нужны только в пределах двух-трех методов
3) Либо код будет содержать Tuple/KeyValuePair, что вообще читабельности не добавляет.
И кортежи решают проблему — у вас появляются анонимные типы (статически типизированные и с адекватными именами свойств), которые легко шарятся между тремя методами. Т.е. можно писать короткие методы (держа каждый метод на едином уровне абстракции) и не писать лишнего говнокода. На всякий случай: количества смысла и адекватности на одну строку кода повышается.
Не, можно конечно юзать это и во вред проекту. Но в C# есть более опасная фича в виде dynamic, а её никто не спешит юзать без реальной нужды.
Также вместе с кортежами должны идти pattern matching/destructuring. Это по сути возможность написать foreach ((var id, var name) in dictionary)
1) Либо один большой говнометод
2) Много непонятных data-классов, которые нужны только в пределах двух-трех методов
3) Либо код будет содержать Tuple/KeyValuePair, что вообще читабельности не добавляет.
Всё верно — если программист решая задачу сталкивается с выбором из этих 3 пунктов, очевидно он сам не понял что напрограммировал. Есть большая разница между «кодом, который выдаёт нужные результаты» и «кодом, который решает задачу»: в первом случае просто проходят тесты, а во втором — в явном виде описываются намерения: вводятся термины, связи между ними, и уже в контексте этого небольшого «под-домена» описывается решение задачи.
Обратите внимание, ваше описание решаемой проблемы начинается с фразы «Вот пишешь ты метод, в нем юзаешь анонимный тип» — проблема появляется уже здесь, а не в момент «extract method»: вы посчитали, что «вот эта сущность» недостаточно важна, чтобы вводить её в явном виде, и ввели неявно. На следующем шаге вы об этом начинаете горько сожалеть, т.к. выясняется, что именно эта сущность связывает несколько частей решения задачи.
вы посчитали, что «вот эта сущность» недостаточно важна, чтобы вводить её в явном виде, и ввели неявно
О, мы нашли точку непонимания. Вы считаете, что если сущность шарится между методами, то она важна. Это не так. Возможно у вас не встречалось задач, в которых есть сущность настолько мелкая, что писать на неё лишний тип и придумывать осознанное адекватное имя нецелесообразно. Да, она связывает несколько «частей» решения задачи, и что?
У меня каждая часть решения состоит из двух-четырех строк — у меня в этой задачи главное методы, а не данные. Вы правда мне предлагаете выделять новый тип данных? Завести отдельный файлик под структуру, перечислить требуемые неймспейсы, указать неймспейс сущности, указать что за сущность, указать два свойства сущности, разделив их пробелами по гайдлайнам. У меня есть код в 10 строк, вы предлагаете добавить еще 10 строк и один файл, запутав остальных в проекте самим существованием левой модели?
Я предпологаю, что у вас нету понимания, что некоторые задачи нужно решать, продумывая типы данных (ООП и прочее); а в некоторых задачах нужно писать код (функции). А если я начну городить больше кода, больше типов, больше классов, то он станет нечитабельным (концентрация смысла на строку резко упадет, а охватить все разумом станет трудно). С другой стороны, если я возьму другую задачу, то мне сначала лучше продумать типы данных, потому что в ином случае мой код будет нечитабельной тыквой. Смесь парадигм несет программисту счастье.
Вы считаете, что если сущность шарится между методами, то она важна.
Т.к. сущность шарится между методами, она является частью внутреннего интерфейса. Интерфейс — важен, будь он внутренний или внешний.
Вы правда мне предлагаете выделять новый тип данных?
Да, я предлагаю не мудрствовать, а просто взять и выделить новый тип данных. Не обязательно так громко, как вы описали: если речь идёт про реализацию одного единственного класса, достаточно сделать внутренний класс. Хотя, вообще говоря, и от лишнего файла Земля не остановится.
А если я начну городить больше кода, больше типов, больше классов, то он станет нечитабельным
Наоборот. В голове намного проще удержать сущность, если у неё есть имя. Удержать в голове «ту штуку, в которой лежат a, b и c» — намного сложнее, т.к. вы не поднимаетесь выше a, b и c — они как были отдельными компонентами, так и остались.
Смесь парадигм несет программисту счастье
И большое проблемы другому программисту, который будет в этом коде разбираться.
Если у вас задача, где нужно писать код, то почему бы не написать ее на F# или другом функциональном языке, а потом, если нужно, подключить его к C#?
И большое проблемы другому программисту, который будет в этом коде разбираться.
Если у вас задача, где нужно писать код, то почему бы не написать ее на F# или другом функциональном языке, а потом, если нужно, подключить его к C#?
Ага вместо того, чтобы понять, что такое кортеж, другому программисту придется учить целый другой язык
Потому что смесь языков не несет счастье. Сесь парадигм несет счастье. Почему так? Потому что код един, в одном формате и не нарушается принцип DRY. В случае когда мы мешаем языки, такого не происходит. Если у нас есть C# (бек) и Javascript (фронт), то происходит дублирование, либо отсутствие на каком-то из слоев какой-то полезной логики, либо изобретаются всякие транскомпиляторы. Если у нас есть C# и F#, то даже в пределах их общий shared код — это просто пи**ец. Не надо рассказывать про то, что они на .NET и легко интероптятся. Я пробовал, я знаю что это не пашет с легкого пинка.
А еще под F# нету многих инструментов и фич, которые есть под C#.
А еще под F# нету многих инструментов и фич, которые есть под C#.
Особенно ржачно выглядит когда человек пытается подключить всякие там IronPython в проект на C#
Кстати, да, сразу пример жизненный приходит на ум. Нередко бывает, что приходится писать огромный EF запрос, и хочется его разбить на несколько методов, иногда и переиспользовать, то ради того, чтоб передать несколько сгруппированых датабазных сущностей приходится заводить класс.
Т.е не сами сущности, конечно, а IQueryable от их группы.
Говнокодеры в этом случае тупо копипастят этот огромный метод, ради того, чтоб в середину еще один .Where() воткнуть, опять же из личной практики. Кортежи, как мне кажется, на способностях лоу-левел разработчиков никак не сыграют.
Т.е не сами сущности, конечно, а IQueryable от их группы.
Говнокодеры в этом случае тупо копипастят этот огромный метод, ради того, чтоб в середину еще один .Where() воткнуть, опять же из личной практики. Кортежи, как мне кажется, на способностях лоу-левел разработчиков никак не сыграют.
Ну как бы тот же LINQ был бы невозможен в том виде что есть без типа dynamic. А в данном случае кортежи упростят местами код и при этом еще помогут соптимизировать конечный код. И чего в данном случае нарушает статическую типизацию? Какой-нить синтаксис вида Tuple<int, string>(1, «text»); для вас приемлем, здесь есть нарушение статической типизации?
Спасибо! Надеюсь что будет и следующая часть — Pattern matching / Records / algebraic data types (Proposal: #206), там еще интереснее:)
Единственное место, где я вижу для них перспективу в большинстве проектов — табличные списки разного формата и DataBaseStyle. Остальное просто убьет «сладостью» весь проект, ничего же не понятно будет.
Задачи с применением такого рода технологии есть в математических фреймворках и цель у нее там несколько иная, нежели удобство, а именно — объединение задач в одну и там не важна читабельность (математика жеж). Например, вычисление одновременно и мат ожидания, и дисперсии, чтобы два раза цикл не гнать, но это такой слабенький пример, есть и покруче.
Задачи с применением такого рода технологии есть в математических фреймворках и цель у нее там несколько иная, нежели удобство, а именно — объединение задач в одну и там не важна читабельность (математика жеж). Например, вычисление одновременно и мат ожидания, и дисперсии, чтобы два раза цикл не гнать, но это такой слабенький пример, есть и покруче.
UFO just landed and posted this here
Нет, такого не будет. Во всяком случаи пока в планах такого я не увидел.
По ссылке
Tuple deconstruction
Since the grouping represented by tuples is most often «accidental», the consumer of a tuple is likely not to want to even think of the tuple as a «thing». Instead they want to immediately get at the components of it. Just like you don't first bundle up the arguments to a method into an object and then send the bundle off, you wouldn't want to first receive a bundle of values back from a call and then pick out the pieces.
Languages with tuple features typically use a deconstruction syntax to receive and «split out» a tuple in one fell swoop:
This way there's no evidence in the code that a tuple ever existed.
Tuple deconstruction
Since the grouping represented by tuples is most often «accidental», the consumer of a tuple is likely not to want to even think of the tuple as a «thing». Instead they want to immediately get at the components of it. Just like you don't first bundle up the arguments to a method into an object and then send the bundle off, you wouldn't want to first receive a bundle of values back from a call and then pick out the pieces.
Languages with tuple features typically use a deconstruction syntax to receive and «split out» a tuple in one fell swoop:
(var sum, var count) = Tally(myValues); // deconstruct result
Console.WriteLine($"Sum: {sum}, count: {count}");
This way there's no evidence in the code that a tuple ever existed.
И кортежи, и паттерн матчинг, и наверняка многое из этого списка есть в F# и используется, как мне кажется, для ограниченного круга задач. Зачем тащить это в C#?
С паттерн матчинг понятно, его давно хотят перетинуть с C#, сколько самописных библиотек по этому написано. Картежи достаточно спорная фича, я согласен, хотя ее прменение вполне понятно и может быть удобным в случаи каких то еденичных возвратов. Я бы допустим применил ее при выгрузке некоего не большой объекта на веб страницу с сериализацией в JSON.
Очень спорная фича по нескольким причинам. Во-первых, почему решили придумать новый синтаксис для практически того же, что уже делают анонимные типы, а не расширить их возможность? Во-вторых, почему именно структура? Например, следующий код не сработает:
var list = new List<(int X, int Y)>();
list.Add((1, 2));
list[0].X = 2; // ошибка: потеряли lvalue
Я не очень понял, почему ошибка можете поянить?
Потому, что индексатор
List<T> — это присыпанная синтаксическим сахаром функция. Из нее возвращается копия структуры, поэтому лежащее в списке значение не может быть изменено присваиванием. С массивом ситуация обстоит по-другому: там индексатор реализован с помощью отдельной инструкции, позволяющей обратиться непосредственно к объекту по адресу.Я одного не понял. Будут создаваться таки анонимные структуры или классы? Потому что если структуры, фича куда более, чем просто сомнительна.
Обоснование у создателей на создание анонимных структур, а не классов, вот такое
Struct or class
As mentioned, I propose to make tuple types structs rather than classes, so that no allocation penalty is associated with them. They should be as lightweight as possible.
Arguably, structs can end up being more costly, because assignment copies a bigger value. So if they are assigned a lot more than they are created, then structs would be a bad choice.
In their very motivation, though, tuples are ephemeral. You would use them when the parts are more important than the whole. So the common pattern would be to construct, return and immediately deconstruct them. In this situation structs are clearly preferable.
Structs also have a number of other benefits, which will become obvious in the following.
Struct or class
As mentioned, I propose to make tuple types structs rather than classes, so that no allocation penalty is associated with them. They should be as lightweight as possible.
Arguably, structs can end up being more costly, because assignment copies a bigger value. So if they are assigned a lot more than they are created, then structs would be a bad choice.
In their very motivation, though, tuples are ephemeral. You would use them when the parts are more important than the whole. So the common pattern would be to construct, return and immediately deconstruct them. In this situation structs are clearly preferable.
Structs also have a number of other benefits, which will become obvious in the following.
Sign up to leave a comment.
Что нам готовит C# 7 (Часть 1. Кортежи)