Автоматические свойства в C# 3.0

[yudjin]

День добрый. Столкнулся с такой проблемой: в C# 3.0 появились т.н. "Автоматические свойства". Пользовался приблудой - все хорошо, пока не сталкнулся с абстрактными свойствами. Собственно, сеттер теперь нуждается в теле.

Автоматические свойства: компилятор сгенерирует закрытое (private) поле и соответствующие аксессор и мутатор для кода вида

Код:

public string Name { get; private set; }

Код:

    public abstract class Symbol : ISymbol
    {
        public abstract void Draw();
        public abstract Brush SymbolBrush  { get; protected set; }
    }

Код:

    public class SimpleFillSymbol:Symbol, ISymbol
    {

        public override Brush SymbolBrush
        {
            get
            {
                return new SolidColorBrush(FillColor);
            }
            protected set; // SymbolBrush.set must declare a body because it is not marked abstract, extern, or partial	

        }

    }

[Джон]

Не совсем понятно, что ты хочешь сделать.

Если свойство SymbolBrush только для чтения, то выбрасывай set нафиг.

[yudjin]

Уже исправил Согласен, я тупил... Просто вначале задумывалось, что базовые классы, реализующие это свойство, будут его инициализировать через сеттер.

[Джон]

Да, ещё одно забыл. Не по теме, а по оформлению сообщения.

Если ты оборачиваешь код тегом code, то все теги форматирования текста внутри перестают работать. Это, собственно говоря, то, что я исправил в твоём сообщении - удалил теги  [ b ].

[Dimka]

Джон, не, он хочет схалявить

"Автоматическое" свойство - это лишь синтаксический сахар. Когда ты пишешь:

Код: (Text)

public int X { get; set }

Сначала это разворачивается в:

Код: (Text)

private int _X;
public int X
{
  get { return this._X; }
  set { this._X = value; }
}

Само свойство в свою очередь - это тоже синтаксический сахар, который разворачивается в:

Код: (Text)

public int _get_X()
{
  return this._X;
}
public void _set_X(int value)
{
  this._X = value;
}

И только потом собственно копилируется.

Но когда ты пишешь:

Код: (Text)

public abstract C X { get; set }

Это вовсе не "автоматическое" свойство, это обычное свойство. Оно разворачивается лишь по второму правилу:

Код: (Text)

public abstract C _get_X();
public abstract void _set_X(C value);

Т.е., во-первых, никакого поля не появляется - его нужно заводить вручную (причём, как правило, в дочернем классе, поскольку находящийся в родителе абстрактный интерфейс не подразумевает реализации), во-вторых, если ты переопределяешь свойство через override, то тебе нужно определить оба метода - и get, и set. Если ты определишь лишь set, get останется абстрактным, что потребует абстрактности дочернего класса.

P.S. За этот синтаксический сахар, который вносит путаницу в семантику кода, авторов языка C# надо побивать камнями. Лень пару строчек написать. А потом начинающие часами пытаются понять, почему у них ничего не работает.

[yudjin]

Спасибо за развернутый ответ!

[Джон]

Могу только повторить подпись:

"Just because the language allows you to do something does not mean that it’s the correct thing to do." (c) Trey Nash

[KoctyaGold]

P.S. За этот синтаксический сахар, который вносит путаницу в семантику кода, авторов языка C# надо побивать камнями. Лень пару строчек написать. А потом начинающие часами пытаются понять, почему у них ничего не работает.

Но благодаря этому "сахару" уже надо меньше задумываться над писанием кода, а больше сфокусироваться на сути.

[Dimka]

KoctyaGold, у ряда людей и, в частности, Никлауса Вирта, на этот счёт особое мнение. Мнение заключается в том, что хороший язык - это однозначный язык, в котором любая концепция может быть записана только одним единственно возможным образом. Потому что программирование - это не художественное творчество, а математическая и инженерная дисциплина.

Не вижу никакой выгоды в том, чтобы вместо одного однозначного выражения разучивать десять неоднозначных вариантов, а потом вместо "сути" думать о том, чего это оно по сути не работает.

[resource]

Вирт, как и любой из нас, вправе иметь свое собственное мнение. И хотя в некотором смысле он авторитет, но думать, что его мнение единственно верное, я бы не стал. Это не более чем консервативные взгляды людей, которые в силу возраста и собственной "закостенелости" не хотят (не [не могут], а не хотят) постигать новое и двигаться вперед (все устают).
Лично я соглашусь с неавторитетным мнением никому неизвестного KoctyaGold. Писать можно по разному. А если человек пишет что-то, сам не понимая что, то он и на Си чудить может (это к слову об однозначных языках).

[Dimka]

resource, рассуждения о прогрессе я бы поделил на две категории.

Одни люди рассуждают о прогрессе вообще, радуются всему новому, потому что оно не такое как старое, и специально аппелируют к новому, чтобы выразить своё недовольство старым. Самое главное, что в этом случае недовольство старым получается каким-то эмоциональным, не имеющим чёткой и внятной рациональной позиции.

Другие люди о прогрессе не рассуждают, они его делают: берут и создают нечто новое, при этом обязательно опираясь на старое по той же причине недовольства старым. Но когда они это делают, они точно знают, чем именно старое неудобно в той или иной деятельности. Поэтому у таких людей новое - это не принципиально новое, а развитие старого. Тот же Вирт за свою жизнь создал последовательность языков: Паскаль, Модула, Оберон. Причём Паскаль он делал, опираясь на Алгол. Все эти языки имеют общую родовую основу, идущую к Алголу, но каждый из них является попыткой преодоления недостатков предыдущего. Т.е. имеем диалектическое развитие языков. При этом всё полезное (типа автоматический сборки мусора) Вирт включал в свои языки, а весь бесполезный синтаксический сахар, наоборот, исключал.

Лично я для себя хорошо уяснил, что значит "вперёд" в смысле Вирта: это такой синтаксический минимализм, который не ограничивает возможности построения и выражения в языке новых концепций - как чисто программистских, так и из предметных областей. Если посмотреть на цепочку языков Вирта, можно увидеть тот предел, к которому всё движется: Оберон имеет грамматику на пару листиков, позволяет структурировать код не хуже, чем любой развитый ООП язык, и таким образом описывать пользовательские концепции; в силу малого размера Оберон устойчив и живуч - нет необходимости каждые полгода выпускать новую версию, что снимает проблемы совместимости по крайней мере на уровне компилятора; в силу малого размера его код однозначен, а синтаксис легко изучается; в силу простоты языка для него легко пишутся эффективные компиляторы и виртуальные машины, что позволяет применять язык для решения широкого класса задач (от написания операционных систем до разработки веб-приложений, причём способных выдерживать высокие нагрузки). Абсолютно минималистским синтаксисом, на мой взгляд, обладает Лисп, но Вирт остаётся в рамках алгоритмической парадигмы (на это тоже есть свои резоны). Т.е. Вирта "вперёд" имеет чёткую рациональную и во многом научную основу.

Кто мне может описать смысл "вперёд" для C#, кроме "а давайте вставим вот эту прикольную штуку"? Какой язык проще изучать, писать и читать на нём тексты: английский из 26 букв или китайский из 3500 основных и 6500 неосновных иероглифов? Текст на китайском всегда получается гораздо компактнее и выразительнее, образнее и поэтичнее, чем на английском. Хороши ли такие качества для инженерии и производства в рамках западной культуры? Улучшится ли производственный процесс, если рабочий документ (в нашем случае программный код) будет допускать разные трактовки и мнения о его содержании?

[resource]

Я ни в коем случае не пытаюсь приуменьшить "крутость" Вирта. Хотя сам не понимаю в чем она заключается. "Паскаль, Модула, Оберон" - кто сегодня знает хоть что-то о последних двух ? А может быть они много где применялись (даже в то время)? Да даже если и много, кому какая разница. Вот Си и Ассемблеру сколько лет, а ведь и в наши дни на них пишут. Даже на асме много пишут. Про Си то уж и говорить нечего, просто огромное кол-во софта пишется на нем (90% конечно системного). Какая Модула? Какой Оберон? Зачем они нужны? Придумать какую-то "Биллиберду" может кто угодно. Паскаль отдельная песня. Никогда в жизни не видел в нем ничего хорошего. Хотя может он и подходит для обучения основам программирования, не возьмусь об этом судить.

Что касается нелюбви ко всему старому и патологического стремления к чему-угодно, лишь бы было новое......Ну я даже не знаю. Это явно не про меня получилось (даже если и задумывалось). Я системный программист, пишу на Си всю жизнь, вижу каждый день тонны дизассемблерных листингов, мне не нравится "выходить" из ядра в юзермод. Я люблю старое как ни кто другой.
Просто сам в шоке от того, что я вообще всерьез задумался о C#, и даже взялся за него. И слава богу конечно. Но это для меня абсолютно не типично.

Дискуссия-то разрослась. Но возвращаясь к истокам, мне вот непонятно как можно не любить этот самый синтаксический сахар. Столько вещей очень удобных. Ну не умеешь, так ознакомься для начала, а  потом уже пользуйся. Это везде так, что не нужно делать то, что не понимаешь. Вот например, те же лямбды - это ведь тоже синтаксический сахар. И как можно без них писать? Это ж такие некрасивые кучи кода воротить придется. Лямбды вообще на каждом шагу, и не только в C#. Те кто оценил выгоду, уже не будут писать без них. Короче я не вижу проблем с "сахаром", а вот проблемы с кодерами, которые не умеют писать код - это уже другой вопрос, но C# тут не виноват.

[Dimka]

Вот Си и Ассемблеру сколько лет, а ведь и в наши дни на них пишут.

C и ассемблеры - это несопоставимые вещи. Ассемблер - это не более чем мнемоническое обозначение реальных машинных команд (байтиков, интерпретируемых микросхемой). Для каждой процессорной архитектуры он свой. Поэтому "сколько лет на нём пишут" - это неверное утверждение. За все эти годы менялись процессорные архитектуры, и вместе с ними приходили и уходили разные ассемблеры. У ассемблеров более-менее похожим является лишь грамматическая структура.

Про Си то уж и говорить нечего, просто огромное кол-во софта пишется на нем (90% конечно системного).

Язык C изобретался вместе с UNIX, начиная с 1969 года. За истекшие 40 лет язык имел устаканившуюся редакцию K&R 1978 года, кроме того, есть два стандарта C89 и C99. Т.е. в среднем небольшие изменения вносились в язык раз в 10 лет. Если открыть Википедию, первая фраза в разделе "Особенности":

Язык программирования Си отличается минимализмом.

Что я и приветствую. Сравни это всё с C#.

"Паскаль, Модула, Оберон" - кто сегодня знает хоть что-то о последних двух ?

В данном случае меня не интересует "попса", маркетинговая раскрутка, "лапы" крупных корпораций, внедрение в доминирующие ОС и даже богатые библиотеки - все эти факторы гораздо сильнее влияют на популярность и известность языка, нежели внутренние качества самого языка. А я говорю именно о внутренних качествах.

Был такой язык PL/1 - некогда очень популярный. Он обладал одной особенностью - в него всякий мог добавить синтаксический сахар. Этот язык умер, утонув в синтаксическом сахаре, когда программы оказались непереносимы из одной организации в другую, из-за привычек разных программистов к разным сортам синтаксического сахара, когда программисты не могли читать программы друг друга, когда вместо поиска известных решений всякий изобретал свой собственный велосипед, когда никто не мог до конца выучить синтаксис всего, что было в языке.

В рамках C нечто подобное наблюдалось в период расцвета макросов. В конце концов до многих программистов дошло, что обилие макроопределений - это ад для чтения программы и её отладки.

И мне кажется, что C# сейчас, к сожалению, движется в том же направлении. Это не значит, что в C#, начиная с первых версий (а я его знаю и работал с ним с самого начала) не было полезных добавлений. Я, например, приветствую generic types. Однако сочетание анонимных методов, лямбда-выражений и yield возвратов я не приветствую. Потому что это избыточно. Уж или лямбда, или yield-возвраты с блоками кода в замыканиях. Они решают одинаковые задачи. Также я не приветствую сочетание статической и динамической типизиации (с var или (в С++) auto) - это требует разных стратегий разработки и разных навыков программиста, что влечёт разные функциональные требования к компилятору и среде разработки. Получается погоня за двумя зайцами одновременно. При этом сама платформа .NET в общем-то не мешает написать три разных языка: со статической типизацией, с динамической типизацией и функциональный. (Более того, они есть: это C#, зря переделанный на статическую типизацию JavaScript.NET и F#.) И делать решения из модулей и сборок, написанных на этих языках. Оно было бы понятнее и логичнее, хотя, конечно труднее для маркетинговой раскрутки, поскольку отпугивало бы низкоквалифицированных программистов необходимостью "учить" три языка.

[Джон]

Начну с того, что я ща работаю в студии 2010 с .NET 3.5 и тоже пользую "сахар". И лямбды, и LINQ, и особенно XML LINQ. И дело совсем не в том, что есть кодеры, которые не умеют писать код, или крутые кодеры, которые могут всё. Это очень примитивный аргумент. Давайте посмотрим на вещи объективно. Во-первых, Димка сарзу сказал о новичках.
Это для них понятно? А если ещё и крутой кодер рядом чморит, в ухо дышит типа: "Салага, да это можно одной строчкой записать!". Посему задумайтесь объективно над вопросом, в каком коде новичку легче разобраться?
Во-вторых, абсолютно не согласен с:

Но благодаря этому "сахару" уже надо меньше задумываться над писанием кода, а больше сфокусироваться на сути.

Как раз именно БОЛЬШЕ задумываешься. Конечно, когда у тебя уже есть навык и ты уже привык, тогда меньше задумываешься. Но всё равно задумываешься.
И при чём здесь фокусировка на сути? Какая разница как написан код? Алгоритм - суть - от этого ну никак не изменится. Это больше похоже на браваду: "А я вон как могу!". Опять же, объективно оценивая ситуацию, могу сказать, что да, в некоторых случах ЛИЧНО МНЕ действительно удобно писать в "сахарном" коде. "Но боже мой какая скука" (с) разбираться в таком "сахаре", который написал колега, незная алгоритма, задачи и тд. Отладка, поиск ошибок, да просто code review при интимной (in team) работе. В этом плане хорошо программерам-одиночкам. В команде такой "сахар" зачастую превращается в потерянные минуты, а то и часы.

Сравним простейший "сахар"  с несахаром.

Код:

foreach(myClass item in myList)
{
...
}

v.s.

myList.ForEach(item => item ...);

Конечно сахар короче. Но теперь вам надо пройтись по этому участку кода дебаггером. И что?

Короче, объективно, "сахар" в C# можно сравнить с записью кода С++ в одной строчке. Под девизом: "Чем непонятней, тем круче!". Но кто так делает в С++?

[resource]

Вообще конечно есть минусы. То что Джон сказал по поводу дебагера, а так же невозможность изменения "на лету" функции, которая содержит те же лямбды. В остальном - кому что. Мне слаще с сахаром 

[Вад]

Alan Perlis вспомнился вот:

Syntactic sugar causes cancer of the semicolon

Впрочем, на мой вкус, есть разные сорта сахара.

Сахар общепринятый (как ' вместо quote в LISP или, скажем, оттуда же, из мира ФП, всякие let-нотации; или оператор [] в С) - он здорово облегчает жизнь, потому что все про него знают, и не нужно писать длинных конструкций, которые лежат в его основе. Здесь сахар, наверное, по сути ближе к библиотечной обёртке, чем к синтаксису языка.  

А вот сахар, который глубоко и щедро засыпан в сам язык, мне видится скорее вредным. Потому что им редко пользуются по делу, чаще присыпают дурно пахнущий код.
Например, однажды попалось на глаза импровизированное соревнование в количестве способов сгенерировать какой-то неспложный список на Python (для этого точно есть библиотечная функция): там и самописные генераторы были, и на циклах что-то такое, и чего только не было. Участников ничуть не смущало, что почти все предложенные способы - это не т.н. "Python way". Да стоит просто зайти на Stackoverflow: местами страшно становится, до чего разнообразными могут быть решения (и до чего фриковатыми могут быть отдельные из них) - а потом можно много спорить о том, какое из решений в текущей реализации компилятора/интерпретатора работает эффективнее (чтобы уже в следующей версии всё это знание устарело).