Дмитpий Hecтepук

Блог о программировании — C#, F#, C++, архитектура, и многое другое

Мысли о «новом» обещанном нам C#

9 комментариев

Как вы понимаете, Microsoft сейчас толком не до языковых фич т.к. сам компилятор переделали и даже уже сами переключились на Roslyn в процессе разработки, что как бы намекает на большие планы на 2014. Соответственно, те фичи которые Мадс осветил на NDC London не являются системообразующими, поэтому получите список:

  • Первичный конструктор в стиле class Size(int cx, int cy) { ... }, где как вы догадались, cx и cy это значения которые потом можно присвоить пропертям. Позволяет писать new Size(320,240), и вообще своровано с F#.
  • Возможность задавать значения readonly свойствам в стиле public int Width { get; } = cx. Даже не знаю что тут сказать – у меня часто свойства еще и в UI используются, а там все равно будет поле, так что нет разницы. (Ждите от Roslyn автореализации INPC? Не дождетесь.)
  • Property expressions, т.е. возможность писать property get без собственно блока get{}, return и прочих излишеств:
    public int Area => Width * Height;
    
  • Та же тема для методов. Фактически, просто удаление скобочек и return, но я уже вижу как новички пихают в эти стейтменты всякий мусор:
    public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
    
  • params IEnumerable, потому что когда хочется неограниченное число аргументов, то IEnumerable удобнее чем массив? На самом деле, могли как в D попробовать делать вещи через convention over configuration, т.е. вместо ключевого слова params просто сказать, что если есть только один параметр и он IEnumerable<T> или T[], то давать пользователям передавать массив через Foo(a,b,c) – и все были бы довольны.
  • Monadic null checking означает что вместо person.With(x => x.Address).With(x => x.HouseName) можно написать person?.Address?.HouseName, и везде будут проверки на null. Шикарно конечно, может немного поздновато, к тому же как показала практика, проверка на null – это не единственный concern, которых можно вкладывать в цепочки из лямбд.
  • Вывод типов для конструкторов, т.е. вместо Tuple.Create(foo,bar) можно наконец-то писать new Tuple(foo,bar)
  • Инлайновые декларации для out параметров по мне так самый большой фейл, пожалуй. Идея в том чтобы можно было писать
    if (foo.TryGetValue(out int x))
    {
      // use x, it's already been declared!
    }
    

    Ну и конечно идея в том что если параметров возврата несколько, то это как бы упрощает жизнь. Знаете что еще упрощает жизнь?

    let (x1,x2) = SolveQuadratic(1,10,16);
    

    И не важно, получили ли мы кортеж из (x1,x2) или просто две переменных – главное что результат метода записывается в том месте, в котором вы ожидаете, а не в аргументе, где декларации переменной – явно не место.

  • Импорт типа в пространство имен: уже хорошо, сделаем using System.Math чтобы не пользоваться поистине невменяемыми с точки зрения здравого смысла конструкциями вроде Math.Sin(). Хотя это только полумера: еще нужно удалить заглавные буквы (ну зачем они?), добавить оператор возведения в степень (с целочисленной перегрузкой), и уже будет можно дышать. Но разве ж кто-то об этом думает?

Ничего из списка выше особо не впечатляет. Гораздо интересней сам Roslyn (все же надеюсь что он будет «готов» к VS2014), ну и как это не странно, С++ сейчас развивается как-то быстрее, причем без всякого переписывания компилятора. ■

Реклама

Written by Dmitri

21 декабря 2013 в 13:36

Опубликовано в C#

комментариев 9

Subscribe to comments with RSS.

  1. Пошарпанный шарпик какой-то теперь. Когда я увидел впервые эти предложения ещё на Реддите, первой мыслью было, что это очередной несостоятельный пакет из серии «а вот я бы сделал это вот так». Но потом новость попала в Хабр, теперь и сюда, что меня весьма удивило. Тогда было даже даже подумал, что это скорее шутка. В целом, крайне сомнительные возможности. К сожалению, давно не пишу на C#, в силу того, что судьба свела с Java, но хочу сказать, что Java как язык развивается хоть и медленно, но более взвешенно и грамотно, что ли. Оговорюсь, что о Roslyn едва слышал, но _это_ прокоментировать хочется.

    1) Первичный конструктор. Не нужен.

    2) R/O-свойства. Сомнительно. Синтаксис страшный, и както несвязно выглядит в сочетании со следующими пунктами о сокращении записи коротких методов и свойств. Почему не какой-нибудь public int Property { get => 1 }, например?

    3) Выражения свойств и методов. В принципе, не плохо, не ново, можно злоупотреблять.

    4) params IEnumerable. Почему просто не передать IEnumerable?

    5) Не вижу много пользы. Также мне кажется весьма спорной вещью сам способ доступа к цепочке свойств таким образом: сколько времени уже пишу код, но стараюсь не допускать таких сценариев вообще. Похоже на code smell, а так, возможно, имеет смысл в шаблонизаторах.

    6) Вывод типов для конструкторов. Неплохо. Фактически решено «diamond»-оператором в Java 7, хоть и с рядом своих ограничей и совсем другого подхода к выводу типов, в зависимости, от типа объекта, к которому присваивается значение.

    7) Встроенные объявление out-переменных. Дикость. Опыт показывает, что работа с out по большому счёту не нужна вообще, и скорее всего свидетельствует о плохом дизайне, не важно с какой стороны (я предполагаю, что множество out-параметров упрощает работу с COM-объектами). Вменяемые кортежи, если бы присутствовала такая поддержка, выглядят немногим чище, препятствуя, по большому счёту, засилию суррогатов разных мастей типа Pair / Entry (как часто хочется в Java), так и Tuple, который, как мне кажется, спокойно можно было бы маскировать под видом какой-нибудь языковой конструкции. Тем не менее, кортежи лишены семантической нагрузки. Вообще.

    8) Импорт типа в пространство имён напоминает статический импорт в Java, но, видимо, допускает больше неявно импортированных сущностей, чем нужно. Своего рода, необузданность и непредсказуемость, как в случае с импортом методов расширений.

    Куда более хочется мета-программирования (я давно уже хочу иметь возможность написать макросами foreach с индексацией, или автоматичски реализовать шаблон Декоратор прямо на этапе компиляции); ссылок на сущности типа полей и методов на этапе компиляции, например, methodof(Console.WriteLine……) — лучше пускай компилятор отловит, нежели рантайм упадёт из-за опечатки в строковой константе + упрощается рефакторинг; поддержки контрактного программирования, похожего на JSR 305 в Java, а не чтобы контрактами занимался рантайм; не-null значения для объектов, типа T! (string!, object!), когда бы null было попросту запрещено присваивать в ссылки такого типа (со временем потребность в ?. попросту бы отпала, или была нужна строго для legacy-кода); возможно, родную поддержку (не)изменяемых и потоко(без)опасных объектов; перечисления как в Java (даже Jon Skeet не против такой идеи «class enum»), какой-нибудь поддержки IoC/DI и т.д.

    Lyubomyr Sh.

    21 декабря 2013 at 14:43

    • Спасибо за развернутый комментарий, вообщем-то со всем согласен, разве что не соглашусь с тем что Java развивается более грамотно — скорее правильно сказать, что Java пала жертвой обратной совместимости и не совсем мудрых решений («делегаты не ООП и нам не нужны» — 1991 год), ну и опять же, community process по сравнению с жесткими требованиями Microsoft — все-таки другая вещь. Не то чтобы я склонен ругать Java, т.к. пока что она рулит миром, но смотреть на нее как на пример для подражания мне кажется некорректно.

      Dmitri

      21 декабря 2013 at 20:29

  2. Мне хочется Розлин, надоело их ждать. А упомянутые перделки — пусть будут, их невысокий уровень «вау-эффекта» лишь доказывает, что в целом C# более-менее сложился и удобен.
    И да, тоже хочу «let (x1,x2) = SolveQuadratic(1,10,16);» — почему эти индусяры никак не запилят?

    Jaja

    21 декабря 2013 at 17:26

    • Да, юзабельные кортежи это достаточно серьезный фейл, который в F# прекрасно работает (хотя до F# 3.0, именовать кейсы дискриминированных объединений, например, было нельзя). То что сделали сейчас — ужасно. Декларации прямо в параметрах — ну как так можно? Надеюсь что все-таки образумятся, рано или поздно, а иначе просто придется плодить вложенные структуры для обычных возвращаемых значений (а потом становиться на грабли вроде «ой а как их сравнивать»).

      Dmitri

      21 декабря 2013 at 20:32

      • Да, «декларации прямо в параметрах» — это «не наш метод», но…
        постоянно приходится парсить строки, поэтому вариант:
        if (double.TryParse(text, out double result){

        }
        вполне приемлем, чтобы сгладить некоторые углы BCL и, думаю, не более того.

        Анатолий Северин

        22 декабря 2013 at 11:57

  3. Может быть не стоит сгущать тучи? Придутся новые фичи по душе или нет — покажет время.

    Pol

    22 декабря 2013 at 8:06

    • Так а никто не сгущает. К тому же, от новых фич не убежать — не будешь использовать сам — все равно найдешь их в чужом коде.

      Dmitri

      23 декабря 2013 at 9:07

  4. Hi Dimitry
    Do you also have blog in English?
    I’ve learned Russian in high school but it’s quite hard to follow.
    I mean, it’s sad to keep such good content to just one group of people.

    Kristijan

    13 января 2014 at 12:46


Оставить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: