How to become an author
Search
Write a publication
Pull to refresh

Comments 69

Теперь в C# 7 добавилась поддержка сеттеров, геттеров, конструкторов и деструкторов:

Вы имели ввиду финализатор?
This comment wasn’t rated yet0
Да, лучше назвать финализатором. Но с другой стороны, именно метод ~Class() в официальной документации msdn называется деструктор (на русском): https://msdn.microsoft.com/ru-ru/library/66x5fx1b.aspx
А финализатором тогда можно назвать именно метод 
protected override void Finalize()

Некоторая путаница с переводами понятий.
Total votes 1: ↑1 and ↓0+1
а толку от деструкторов, если они вызываются через неопределенные отрезки времени после потери последней ссылки (в сборщике мусора), а не сразу.
Total votes 1: ↑0 and ↓1-1
Да никто их и не рекомендует использовать в продакшене, если честно. Есть Dispose(), который вызывается именно тогда, когда надо.
This comment wasn’t rated yet0
они бы использовались, если бы деструктор вызывался бы сразу, а не в сборщике мусора.
с Dispose вот только using { } для меня избыточный код, поэтому лучше вообще без него.
Total votes 5: ↑0 and ↓5-5
поэтому лучше вообще без него.

это как? с try… finally

Total votes 3: ↑3 and ↓0+3
… а типизированных на этапе компиляции шаблонов так и нет :(
И ведь под капотом оно всё равно создаёт специфичный для каждого каждого использованного дженерик-параметра код, но синтаксиса для того, чтобы явно определять поведение для некоторых типов так и нет.
Total votes 2: ↑2 and ↓0+2
Да, и пока не планируется особо. Наверное, не хотят делать второй C++ все-таки.
Total votes 2: ↑1 and ↓10
Generic-и разворачиваются в общий код для дженерик-параметров в виде объектов, и специфичный код для каждого value-типа.
Объявление 5 конкретных типов «List, List
Total votes 1: ↑1 and ↓0+1
Какой приятный синтаксис! Когда читаю про нововведения очередной версии C#, всегда радуюсь — все так просто и естественно, именно так как ожидаешь (хотя сам пишу в основном на С++).
Total votes 9: ↑6 and ↓3+3
Полностью согласен! Возможно, изменений в каждый релиз не много, но зато все они более-менее проверены.
Total votes 5: ↑4 and ↓1+3

Приятный? Паттерн матчинг выглядит, мягко скажем, уродливо.
Сравните с f#


type Color =
    | Red = 0
    | Green = 1
    | Blue = 2

let printColorName (color:Color) =
    match color with
    | Color.Red -> printfn "Red"
    | Color.Green -> printfn "Green"
    | Color.Blue -> printfn "Blue"
    | _ -> ()

Да и поддерживается он очень ограничено. Опять же, сравните с F#

Total votes 4: ↑4 and ↓0+4

Был и мне кажется что switch это самый не удобный оператор притянутый их с++ лучше бы его упростили то примерно такого


switch(shape)
{
    Circle c:
        WriteLine($"круг с радиусом {c.Radius}");
    Rectangle s when (s.Length == s.Height):
        WriteLine($"{s.Length} x {s.Height} квадрат");
    Rectangle r:
        WriteLine($"{r.Length} x {r.Height} прямоугольник");
    null:
        throw new ArgumentNullException(nameof(shape));
    default:
        WriteLine("<неизвестная фигура>");
}
Total votes 7: ↑6 and ↓1+5
Когда давным-давно после паскаля я стал изучать си, то все эти case для каждой ветки тоже казались громоздкими. А теперь вот думаю что это грамотное решение: каждая ветка начинается с конкретного ключевого слова, а не с фиг знает чего. Особенно с учетом того, что в аргументе case в принципе можно писать всякие навороченные выражения, важно четко выделять границы между аргументом case и телом блока.
Total votes 7: ↑6 and ↓1+5
В Rust'е эту проблему просто решают правильным форматированием веток match'a и не плачут… наверное можено все-таки без case обойтись.
Total votes 4: ↑1 and ↓3-2
Чем меньше возможностей выстрелить в ногу, тем лучше.
Ключевое слово «case» должно быть. А вот «break» напрягает.
Total votes 2: ↑2 and ↓0+2
Тоже напрягает. Мне кажется логичным, что если 2 case подряд — то к одному блоку, а если между ними есть код, то каждый относится к своему. Им, видимо, показалось логичным избежать путаницы с ++, где без break можно уйти в соседнюю ветку, хотя в # так сделать нельзя и break выглядит излишним.
This comment wasn’t rated yet0
«Сопоставление» выглядит интересным разве что в case случае. Есть ещё полезные примеры на эту тему?
This comment wasn’t rated yet0
Пока паттерн матчинг полезен действительно, скорее в switch. В следующих релизах должны добавить еще мета, где можно будет его использовать.
This comment wasn’t rated yet0

думаю нормальный синтаксис сопоставления образцом может заменить и if и switch. Т.е. они станут как бы не нужны, потому что можно будет писать короче


match {
  patern1: action1;
  patern2: action2;
  default: actionDefault;
}
Total votes 1: ↑1 and ↓0+1
out по мне не надо было трогать. Да, удобно, но не скажется ли понимании кода
Total votes 3: ↑2 and ↓1+1

По мне так это давно напрашивалось. И локальные функции это отлично. Вот бы еще побольше вывода типов входных и выходных значений и получился бы F# с синтаксом C#.

Total votes 5: ↑4 and ↓1+3
UFO just landed and posted this here
Скачайте последнюю версию — Preview 4, должно заработать — кроме тех случаев, что оговорены отдельно (не все фичи пока поддерживаются в полном объеме).
Total votes 1: ↑1 and ↓0+1

Почему не добавили автоматический вывод типов параметров? Боятся конкурировать с F#?

This comment wasn’t rated yet0
Думаю, в некотором роде да, потому что иначе C# станет слишком похож на F#, вряд ли это и есть стратегия Microsoft.
This comment wasn’t rated yet0
Я не программист на c#, однако имхо из вполне чистого и красивого синтаксиса делают сложно читаемое, сложно понимаемое и сложно парсерное нечто :/
Total votes 12: ↑2 and ↓10-8
Я программист на с# и это просто ужасно :( назвали бы этот кошмар c## или как-то еще, чтобы людей с толку не сбивать.
Total votes 8: ↑2 and ↓6-4
… и сложно парсерное нечто
парсер кода уже написан — Roslyn, бери и пользуйся. Это не проблема.
Total votes 6: ↑5 and ↓1+4
Да, мне тоже не по душе большое количество синтаксического сахара, но новые примочки кажутся вполне удобными. Код становится более лаконичным и понимаемым, а писать в старом стиле никто не запрещает.

Что плохо, так это возможность обфускации кода, например, объявление переменных в виде:
if (0 is var start && 100 is var count) ...
Total votes 1: ↑1 and ↓0+1
а вас за уши заставляют это все использовать? всему этому сахару есть ручной аналог.
Total votes 2: ↑2 and ↓0+2
Не совсем так. Например, в блоке «catch» нет ручного аналога для фильтра «when».
Можно, конечно, вместо
catch (...) when (condition)
{
    ...
}
написать
catch (...)
{
    if (condition)
    {
        ...
    }
    else throw;
}
, но семантика тут будет другая. В первом случае не будет осуществляться разворот стека.
Total votes 1: ↑1 and ↓0+1
То есть когда «when» используется в «case» — это сахар, а в «catch» — не сахар? Нелогично же!
This comment wasn’t rated yet0
разница в том во что разворачивается конструкция.
catch when это exception filters, фича низкого уровня ранее недоступная C#.(она есть в VB.NET)
using это сахар, он разворачивается в try finally Dispose.
Total votes 1: ↑1 and ↓0+1
Я знаю, во что она разворачивается. Я просто пишу об отсутствии логичности: в одном случае это низкоуровневая фича, в другом — синтаксический сахар.
This comment wasn’t rated yet0
я только что описал разницу, вы все еще не видите логики?
без сахара можно легко жить и добиться того же.
а вот без фичи, повторить тоже самое уже не выйдет.
Total votes 1: ↑1 and ↓0+1
Представляю себе количество разностильного кода — кто вручную, кто с сахаром, кто перемешивает. В целом сахар неплохой, но вот делать для ctor/dtor лямбды никакого смысла не вижу — экономия копеечная.
This comment wasn’t rated yet0
И всё же это не лямбды. Просто короткая запись с использованием лямбда-оператора.
This comment wasn’t rated yet0
Само собой — оно только внешне похоже. И все же сокращение только за счет фигурных скобок мне не нравится — раньше свойства и методы визуально легко разделялись. Теперь же это усложнилось, вдобавок будут короткие методы. которые в одну строку, и есть длинные со скобками. В style guide'ах добавятся пункты, чтобы в ревью не возникали священные войны. В общем, пространства для вкусовщины теперь больше.
This comment wasn’t rated yet0
Шаблоны (patterns) есть, кортежи есть, но шаблонов кортежей нет?
Шаблоны наиболее полезны для работы с кортежами и подобными им объектами (как case class в scala). Странно, если это не реализовано.
Total votes 1: ↑1 and ↓0+1
Ваши пожелания может и разумны, но тогда к ним я хочу унификацию, как в Prolog! )
This comment wasn’t rated yet0
UFO just landed and posted this here
Да, ждем примеры от команды Microsoft, пока с таким поиграться не получится — не поддерживается.
This comment wasn’t rated yet0

Объясните мне кто понял про кортежи System.ValueTuple.


С одной стороны там Item1, Item2, также как в обычном System.Tuple, с другой стороны можно дать осмысленное имя полям — Id, Name.


Вот если я напишу публичную функцию


public (long Id, string Name) GetDto(){ return (1, "1");}

А потом её зареференсю из другой сборки, то что я увижу — Item1, Item2 или же Id, Name ?


Моё мнение, что я должен увидеть Item1, Item2, потому что System.ValueTuple это struct и он не изменяем — но как тогда сохраняется семантика, что первый элемент кортежа назван Id, а второй — Name?
Кто нибудь разбирался, как это под капотом работает?

Total votes 1: ↑1 and ↓0+1
В библиотеке System.ValueType помимо самого System.ValueTuple есть System.Runtime.CompilerServices.TupleElementNamesAttribute, который и сохраняет имена элементов объектов типов System.ValueTuple.

То есть ваш код будет скомпилирован в что-то вроде этого:
[return: TupleElementNames(new[] { "Id", "Name" })]
public ValueTuple<long, string> GetDto(){ return (1, "1"); }
This comment wasn’t rated yet0
return new ValueTuple<long, string>(1, "1");
Конечно.
This comment wasn’t rated yet0
Лично мне очень не хватает возможности перегружать операторы для интерфейсов, да и вообще — для дженериков.
Почему я могу написать метод-расширение:
public static IData<T> Add<T1, T2>(this IData<T> lhs, IData<T> rhs)
но не могу:
public static IData<T> operator + (IData<T> lhs, IData<T> rhs)
?
This comment wasn’t rated yet0
Методы расширения могут только добавлять функционал и вы ничего не сломаете добавив его.
Однако операторы перегружаются и вы можете сломать написанный код который использует оператор.
Если же вы разрешите определять операторы только там где их нет, то расширения сломаются когда оператор определят в самом типе.
Total votes 1: ↑1 and ↓0+1
Не вижу проблемы. Если оператор не определён, то ищутся расширения.

Если же вы разрешите определять операторы только там где их нет, то расширения сломаются когда оператор определят в самом типе.

Точно так же расширения ломаются, когда добавляется одноимённый метод в класс.
This comment wasn’t rated yet0
С методами вы все равно можете использовать расширения статически. Выбрать оператор вы уже не сможете.
This comment wasn’t rated yet0
Ну почему, а вести себя как с расширениями? Вызвал метод "+" с двумя параметрами и ок. Правда, кому оно в таком виде надо, сложный вопрос.
This comment wasn’t rated yet0
как по мне, так C# берет часть фишек из функциональных языков, и зачастую это делает код более читаемым и менее многословным. Но везде нужно знать меру, конечно

Недавно обсуждали в комментах, что C# давно уже движется в сторону забытого нынче Nemerle… высока вероятность, что где-нибудь через 3-4 версии у них будет паритет по фичам и примерно одинаковый синтаксис.

This comment wasn’t rated yet0
Nemerle на самом деле еще немного жив, и писать на нем одно удовольствие и переучиться с C# довольно просто.
Но вот использовать его как основной язык в проекте проблематично, по той причине, что нету для него внятных решений типа ReSharper.
Возможно, когда команда Jetbrains допилят проект Nitra и на нем уже построят следующую версию Nemerle, всем будет счастье.
Total votes 1: ↑1 and ↓0+1
(var first, var middle, var last) = LookupName(id1); // var внутри
По моему это просто чудесно!!! :) Наконец это появилось и в C#!
Total votes 1: ↑1 and ↓0+1
Ммм… Out переменные, кортежи, шаблоны. Хочу ))) А кто может сказать, когда намечается релиз 7 версии C#?
Total votes 1: ↑1 and ↓0+1
Люди добрые, объясните темному бедолаге зачем могут быть нужны локальные функции? Что они делают такое чего не покрывают лямбды?
Total votes 1: ↑1 and ↓0+1
Подозреваю, что это сахар для лямбд и есть. В целом, локальная функция воспринимается (по крайней мере, мной) как что-то более очевидное, чем лямбда — это синтаксически отличный от объявления переменной код.
Total votes 1: ↑1 and ↓0+1
По моему скромному мнению, здесь могут быть две причины: область применения и реализация на уровне фреймворка (компилятора, если будет угодно).

1)Область применения
Лямбда применяется, когда на вход требуется делегат типа Func, Action, Predicate, обработчик события и прочее. И нужно это, дабы не плодить миллионы однострочных хендлеров для миллионов входных типов, улучшить читабельность и концентрацию, чтобы не носится как бешеный по всему исходнику. Плюс позволяет не создавать отдельный метод, если он нужен только один раз.

Локальная функция имеет те же преимущества, но позволяет обернуть любой код. Например, если нужно посчитать несколько значений по одному и тому же алгоритму.

2)Могу ошибаться, но логично предположить, что реализация у них разная.
Лямбда аллоцируется в памяти, а локалка, скорее всего, работает по принципу inline-функций и разворачивается на этапе компиляции.
This comment wasn’t rated yet0
Вряд ли в общем случае получится локальную функцию заинлайнить (например: реккурсия). Но скорее всего можно будет сэкономить на аллокации замыкающего класса и сгенерировать функцию принимающую структуру с параметрами.
This comment wasn’t rated yet0
Делать лямбду из нескольких выражений — все-таки не очень хороший тон, лучше использовать новые локальные функции.
Total votes 1: ↑1 and ↓0+1
Локальная функция — хороший способ не плодить сущности в виде нового класса.
Total votes 1: ↑1 and ↓0+1

Как по мне локальные функции будет очень удобно использовать для реализации какой-либо рекурсии (собственно что и продемонстрировано в примере). Часто есть какая-то оборачивающая public функция, которая внутри себя инициализирует какую-то структуру и передает ее уже основной внутренней рекурсивной функции. Эту структуру можно передавать с помощью аргументов, а можно с помощью полей класса. Оба эти решения не очень хорошо выглядят: в первом случае придется каждый раз передавать эту структуру через рекурсивные вызовы (избыточность и избыточное потребление памяти стека), а в другом — добавляется побочный эффект. Локальные функции как раз и решают обе этих проблемы: аргументы не нужно передавать через сигнатуры, но с другой стороны все объекты являются локальными.

Total votes 1: ↑1 and ↓0+1

У лямбд более громоздкий синтаксис. Требуется явно указывать тип делегата, из-за чего нельзя воспользоваться анонимным типом. Кроме того, если лямбда рекурсивна, требуется двойная инициализация переменной.


Пример из статьи на C# 6 выглядит так:


public int Fibonacci(int x)
{
    if (x < 0) throw new ArgumentException("Не надо негатива!", nameof(x));

    Func<int, Tuple<int, int>> Fib = null;
    Fib = i =>
    {
        if (i == 0) return Tuple.Create(1, 0);
        var p = Fib(i - 1);
        return Tuple.Create(p.Item1 + p.Item2, p.Item1);
    };

    return Fib(x).Item1;
}
Total votes 1: ↑1 and ↓0+1
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr