AVK Selected
Показавшиеся интересными, на мой вкус, посты
C# 6.0
08.12.2013
|
Аноним |
http://adamralph.com/2013/12/06/ndc-diary-day-3/
Имхо, какой то хоть и полезный но хлам.
//primary constructors -
public class Point(int x, int y) { }
//read only auto-properties -
public int X { get; } = x;
//static type using statements -
using System.Math;
//property expressions -
public double Distance => Sqrt(X * X + Y * Y);
//method expressions -
public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
//params for enumerables -
public Point Average(params IEnumerable<Point> points) { }
//monadic null checking -
if (points?.FirstOrDefault()?.X ?? -1) { }
//constructor type parameter inference -
var t = new Tuple(1,2); // infers Tuple<T1, T2>
//inline declarations for out params -
public void Foo(out var x, out var y) { }
Имхо, какой то хоть и полезный но хлам.
08.12.2013 258 комментариев |
Хлам, не хлам, а какое-то движение есть...
Extension properties хочу. Хотя, monadic null checking и constructor type parameter inference тоже ничего.
A>Extension properties хочу. Хотя, monadic null checking и constructor type parameter inference тоже ничего.
Так давно бы перешол на Немерл. Мы уже много лет всем этим пользуемся.
A>>Extension properties хочу. Хотя, monadic null checking и constructor type parameter inference тоже ничего.
VD>Так давно бы перешол на Немерл. Мы уже много лет всем этим пользуемся.
Я на работе с боями пропихиваю Т4 Фантазёр вы, батенька.
A>Я на работе с боями пропихиваю Т4
Надо уже с боями вместо Т4 пропихивать Razor
A>>Я на работе с боями пропихиваю Т4
AVK>Надо уже с боями вместо Т4 пропихивать Razor
Ты предалагешь SQL генерировать с помошью Razor? Все эти @Parameters? Не, спасибо.
A>Ты предалагешь SQL генерировать с помошью Razor?
Да.
A>Все эти @Parameters? Не, спасибо.
На Т4 мусора все равно будет больше. Ну и вместо @ там вроде ? можно.
AVK>Надо уже с боями вместо Т4 пропихивать Razor
Сдается мне, что как мета-тул он будет мало интересен. Разве что как довесок к тому же Т4.
AVK>>Надо уже с боями вместо Т4 пропихивать Razor
VD>Сдается мне, что как мета-тул он будет мало интересен.
Почему?
VD> Разве что как довесок к тому же Т4.
Вот уж как довесок к Т4 он точно не нужен.
VD>>Сдается мне, что как мета-тул он будет мало интересен.
AVK>Почему?
1. Нерасширяем. Поддерживает только шарп и васик.
2. Заточен на языковый сервис в IDE и компилятор.
3. Не позволяет вмешиваться в процесс парсинга/типизации.
4. Не имеет никаких средств ни для декомпозиции, ни для композиции кода.
Единственное его применение — это получение метаинформации о коде шарпа. Это очень узкая ниша. В реальных задачах придется сделать еще 100500 приседаний.
VD>> Разве что как довесок к тому же Т4.
AVK>Вот уж как довесок к Т4 он точно не нужен.
Ну, почему же? Т4 позволяет худо-бедно автоматизировать генерацию кода. Розлин — получить информацию о коде из проекта. Соединяем их вместе и получаем более интеллектуальную систему генерации кода, для тех кто боится использовать Немерл .
A>Я на работе с боями пропихиваю Т4 Фантазёр вы, батенька.
Надо стараться.
VD>Так давно бы перешол на Немерл. Мы уже много лет всем этим пользуемся.
Это реально детский сад какой-то с этой агитацией за Nemerle. Как ты себе представляешь "переход на Nemerle" в коммерческом проекте?
C# — один из самых популярных языков программирования, поддерживаемый фирмой Microsoft, с большой накопленной базой кода во всем мире, с большим сообществом профессионалов и большим выбором программистов, Nemerle — экспериментальный язык от непонятно кого в непонятно каком состоянии с непонятно какими перспективами. Он вообще достиг состояния production? Есть некая Nitra от JetBrains, но это же какой-то другой проект, который еще и не закончен.
Потом, с командой C#-программистов что делать, переучивать? А все ли захотят? Всем ли надо будет прерывать профессиональный опыт C#, чтобы в резюме была строчка с N годами Nemerle, который непонятно кому нужен. Что программиста на собеседовании на C# потом спросят: "Так, значит, вы уже N лет не программировали на C#"? Да он и сам начнет подзабывать C#, если будет на Nemerle программировать.
А как искать новых программистов, давать объявление "Требуется программист Nemerle"? Так и предвижу поток кандидатов.
А что делать с базой кода на C#, переписывать кусками, перемешивать с Nemerle? А если потребуется потом этот Nemerle-C# проект поддерживать с субконтракторами или аутсорсерами? Даже если аутсорсер возьмется, цена точно будет выше из-за экзотического языка. Ну и, опять же, что делать потом с этой базой Nemerle-кода, если проект Nemerle завтра сдохнет?
Ну и, наконец, где доказательства, что в реальных больших и длинных коммерческих проектах с обычными программистами Nemerle дает преимущества?
А>Это реально детский сад какой-то с этой агитацией за Nemerle.
Детский сад — это вот такие вот заявления.
А>Как ты себе представляешь "переход на Nemerle" в коммерческом проекте?
Скачиваешь последнюю версию интеграции и добавляешь новый проект Nemerle в солюшен.
А>C# — один из самых популярных языков программирования, поддерживаемый фирмой Microsoft, с большой накопленной базой кода во всем мире, с большим сообществом профессионалов и большим выбором программистов,
И что? Все это куда-то девается что ли?
Все остается на месте.
А>Nemerle — экспериментальный язык от непонятно кого в непонятно каком состоянии с непонятно какими перспективами. Он вообще достиг состояния production?
Он то давно достиг.
Меня вот такие теоретики как ты прикалывают. Сначала выдал тираду о том что проект экспериментальный, а потом задался вопросом о том в каком состоянии проект.
А>Есть некая Nitra от JetBrains, но это же какой-то другой проект, который еще и не закончен.
Который пишется на этом "экспериментальном" проекте, а почему-то не на C#, хотя все члены команды владеют шарпом в совершенстве.
И другие пишут.
А>Потом, с командой C#-программистов что делать, переучивать? А все ли захотят? Всем ли надо будет прерывать профессиональный опыт C#, чтобы в резюме была строчка с N годами Nemerle, который непонятно кому нужен. Что программиста на собеседовании на C# потом спросят: "Так, значит, вы уже N лет не программировали на C#"? Да он и сам начнет подзабывать C#, если будет на Nemerle программировать.
А>А как искать новых программистов, давать объявление "Требуется программист Nemerle"? Так и предвижу поток кандидатов.
А>А что делать с базой кода на C#, переписывать кусками, перемешивать с Nemerle?
Да что хочешь. Можешь оставить как есть. Шарп и Немерл совместимы как Шарп и Васик (и даже больше). Хочешь библиотеку на одном для другого напиши. А если очень надо, то шарповский код можно напрямую добавлять в немерловые проекты. Немерл уже пару лет умеет компилировать широкий сабсет 4-го шарпа.
А>А если потребуется потом этот Nemerle-C# проект поддерживать с субконтракторами или аутсорсерами?
Значит будешь поддерживать. Или сиди и соси лапу.
А>Даже если аутсорсер возьмется, цена точно будет выше из-за экзотического языка.
Тут все просто. Если ты делашь ставку на быдлокодеров, в простонародье называемых индусами, то этот язык не для тебя. Этот язык для тех кто хочет увеличить свои возможности, свою производительность. Кто не хочет ждать милостей от МС или Оракла, а хочет сам добавлять в язык то что ему нужно.
А>Ну и, опять же, что делать потом с этой базой Nemerle-кода, если проект Nemerle завтра сдохнет?
А если сдохнет Шарп? МС тоже не вечна.
Я как бы от тебя, наверно, мало чем отличаюсь. Но когда мне что-то не понравилось в компиляторе, то пошел и поправил это.
А такие как ты сидят и дестялетиями бубнят себе под но — "А что мы будем делать если проект сдохнет?...". Он не сдохнет пока он нужен хотя бы одному толковому программисту. А это случится только, если появится язык существенно луче и люди перейдут на него.
А>Ну и, наконец, где доказательства, что в реальных больших и длинных коммерческих проектах с обычными программистами Nemerle дает преимущества?
Для тех кому нужны доказательства есть шарпы и еще более убогие явы. Вы можете сидеть и годами ждать когда МС реализует вам оператор ?. А я пошел и сделал его за час работы.
Лично мне доказательства не нужны. Я просто использую его в не маленьком проекте. И делаю это не первый раз. И не я один, надо заметить.
А вы бойтесь дальше. Ждите мифических доказательств.
А>Что программиста на собеседовании на C# потом спросят: "Так, значит, вы уже N лет не программировали на C#"?
Извини, но это собеседование на джуниора, для которого знание языка C# имеет весомое значение. Для них прям в вакансиях пишут — знание языка C#.
А>Да он и сам начнет подзабывать C#, если будет на Nemerle программировать.
Не начнет. Но возвращаться будет больно.
Влад прав, применять Немерл имеет смысл для опытных людей, которым не хватает остальных способов борьбы со сложностью. В руках джуниора он будет лишь чуть более привлекателен синтаксически и менее привлекателен без решарпера.
С другой стороны Влад не прав в том, что язык вполне готов к продакшену, тем не менее я его несколько раз там использовал и не жалею об этом. Решения тех задач без немерла стоили бы заметно дороже. Хотя я буду очень рад, когда наконец доведут до ума Найтру и перепишут немерл на ней.
А>
А в чем смысл?? чем это лучше public Point Move(int dx, int dy) { return new Point(X + dx, Y + dy); }
return убрали, да вместо скобок "=>" поставили ?? чёто не очень.
Собственно главный вопрос: ГДЕ pattern matching ???
J>Собственно главный вопрос: ГДЕ pattern matching ???
В Немерле.
А>>
J>А в чем смысл?? чем это лучше public Point Move(int dx, int dy) { return new Point(X + dx, Y + dy); }
J>return убрали, да вместо скобок "=>" поставили ?? чёто не очень.
Можно предположить что на Expression можно будет разбирать отдельные методы а не только выражения. Как в F#.
A>Здравствуйте, Jack128, Вы писали:
А>>>
J>>А в чем смысл?? чем это лучше public Point Move(int dx, int dy) { return new Point(X + dx, Y + dy); }
J>>return убрали, да вместо скобок "=>" поставили ?? чёто не очень.
A>Можно предположить что на Expression можно будет разбирать отдельные методы а не только выражения. Как в F#.
Не понял, честно говоря. Можно примером пояснить?
A>>Можно предположить что на Expression можно будет разбирать отдельные методы а не только выражения. Как в F#.
J>Не понял, честно говоря. Можно примером пояснить?
ровать
Я имел в виду Code Quotations F#. Но ошибся.
J>>А в чем смысл?? чем это лучше public Point Move(int dx, int dy) { return new Point(X + dx, Y + dy); }
J>>return убрали, да вместо скобок "=>" поставили ?? чёто не очень.
A>Можно предположить что на Expression можно будет разбирать отдельные методы а не только выражения. Как в F#.
Сильно вряд ли. Это ограничение искусственное. Процессоры Expression очевидно не умеют интерпретировать весь C#, только экспрешны. Сильно вряд ли Linq Provider будет в курсе, как интерпретировать switch или yield. Вот и обрезали до экспрешнов.
I>Здравствуйте, achmed, Вы писали:
J>>>А в чем смысл?? чем это лучше public Point Move(int dx, int dy) { return new Point(X + dx, Y + dy); }
J>>>return убрали, да вместо скобок "=>" поставили ?? чёто не очень.
A>>Можно предположить что на Expression можно будет разбирать отдельные методы а не только выражения. Как в F#.
I>Сильно вряд ли. Это ограничение искусственное. Процессоры Expression очевидно не умеют интерпретировать весь C#, только экспрешны. Сильно вряд ли Linq Provider будет в курсе, как интерпретировать switch или yield. Вот и обрезали до экспрешнов.
Switch и пр. существуют в природе http://msdn.microsoft.com/ru-ru/library/dd268013(v=vs.110).aspx, только сахара нет.
Чем черт не шутит, добавят в C# 7.0
A>>>Можно предположить что на Expression можно будет разбирать отдельные методы а не только выражения. Как в F#.
I>>Сильно вряд ли. Это ограничение искусственное. Процессоры Expression очевидно не умеют интерпретировать весь C#, только экспрешны. Сильно вряд ли Linq Provider будет в курсе, как интерпретировать switch или yield. Вот и обрезали до экспрешнов.
A>Switch и пр. существуют в природе http://msdn.microsoft.com/ru-ru/library/dd268013(v=vs.110).aspx, только сахара нет.
A>Чем черт не шутит, добавят в C# 7.0
А я где то сказал, что этого нет в природе ? Ни один из LInq провайдеров не умеет этих свичей. Так понятно ?
I>Сильно вряд ли. Это ограничение искусственное. Процессоры Expression очевидно не умеют интерпретировать весь C#, только экспрешны. Сильно вряд ли Linq Provider будет в курсе, как интерпретировать switch или yield. Вот и обрезали до экспрешнов.
У тебя причина попутана со следствием. Linq провайдеры не интерпретируют switch, потому что генерация компилятором expressions обрезана до экспрешинов. Сделать же разбор switch не представляет особого труда. Была бы в этом необходимость.
И, кстати, yield — это сахар, ему ничего не соответствует ни в ET, ни в MSIL.
A>Можно предположить что на Expression можно будет разбирать отдельные методы а не только выражения. Как в F#.
Это было бы чересчур смелое предположение.
J>А в чем смысл??
В том что меньше мусорного кода.
А>http://adamralph.com/2013/12/06/ndc-diary-day-3/
А>
А>//primary constructors —
А>public class Point(int x, int y) { }
А>//read only auto-properties —
А>public int X { get; } = x;
А как это работает ?
Что означает "= x" ? Это инициализация или имя переменной ?
Можно ли как в Nemerle ?
Или так с инициализаций по умолчанию?
А>//static type using statements —
А>using System.Math;
Давно пора
А>//property expressions —
А>public double Distance => Sqrt(X * X + Y * Y);
А>//method expressions —
А>public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
Проще разрешить выражения и убрать 'return', тогда не нужно ничего придумывать и использовать обычные свойства и методы.
А>//params for enumerables —
А>public Point Average(params IEnumerable<Point> points) { }
Я так понимаю для этого нужно менять рантайм. Верно ?
А>//monadic null checking —
А>if (points?.FirstOrDefault()?.X ?? -1) { }
Полезная фича, давно реализуемая в других языках.
А>//constructor type parameter inference —
А>var t = new Tuple(1,2); // infers Tuple<T1, T2>
Ну наконец.
Хотя наверное только из конструктора выводит, или как в Nemerle где может вывести из использования ?
А>//inline declarations for out params —
А>public void Foo(out var x, out var y) { }
Практикуют программирование на 'out' типах ?
Не проще ли кортежи добавить в язык ?
На мой взгляд как раз в публичных методах, которые являются контрактом класса, как раз не нужен вывод типов.
А>
А>Имхо, какой то хоть и полезный но хлам.
_NN>Здравствуйте, Аноним, Вы писали:
А>>http://adamralph.com/2013/12/06/ndc-diary-day-3/
А>>
А>>//primary constructors —
А>>public class Point(int x, int y) { }
А>>//read only auto-properties —
А>>public int X { get; } = x;
_NN>А как это работает ?
_NN>Что означает "= x" ? Это инициализация или имя переменной ?
x в данном случае — это поле. Обрати внимание на primary constructor выше, скорее всего как F#, его параметры в поля преобразуются.
А>>//params for enumerables —
А>>public Point Average(params IEnumerable<Point> points) { }
_NN>Я так понимаю для этого нужно менять рантайм. Верно ?
нафиг? params — это ж вроде как просто указание, что вызов Average(1,2,3,4) преобразовывать в Average(new[] {1,2,3,4}). Причем тут вообще рантайм?
А>>>
А>>>//primary constructors —
А>>>public class Point(int x, int y) { }
А>>>//read only auto-properties —
А>>>public int X { get; } = x;
_NN>>А как это работает ?
_NN>>Что означает "= x" ? Это инициализация или имя переменной ?
J>x в данном случае — это поле. Обрати внимание на primary constructor выше, скорее всего как F#, его параметры в поля преобразуются.
А зачем оно тогда нужно ?
Почему в поля ? Я как раз думаю в случае C# будут свойства для чтения.
А>>>//params for enumerables —
А>>>public Point Average(params IEnumerable<Point> points) { }
_NN>>Я так понимаю для этого нужно менять рантайм. Верно ?
J>нафиг? params — это ж вроде как просто указание, что вызов Average(1,2,3,4) преобразовывать в Average(new[] {1,2,3,4}). Причем тут вообще рантайм?
Ну так оно и сейчас так через массив.
Я так понимаю фишка в том, что IEnumerable как раз даст возможность не создавать массив вообще, а скажем , разместить все в стеке.
Иначе снова неясно зачем это.
Массив он и так IEnumerable.
_NN>Иначе снова неясно зачем это.
_NN>Массив он и так IEnumerable.
Сейчас можно передавать только существующий массив или список аргументов (который преобразуется в массив в месте вызова).
А с params IEnumerable<T> можно будет, кроме того, передавать любые коллекции: List<T>, HashSet<T> и т.д., избегая от ненужного вызова .ToArray() и копирования элементов.
N>Сейчас можно передавать только существующий массив или список аргументов (который преобразуется в массив в месте вызова).
N>А с params IEnumerable<T> можно будет, кроме того, передавать любые коллекции: List<T>, HashSet<T> и т.д., избегая от ненужного вызова .ToArray() и копирования элементов.
Теперь логично, а то я уже подумал про супер оптимизацию для params
N>...
Вы бы хоть какой-нить простенький type-switch замутили. Ну, жудко же не удобно писать в стиле:
Про ПМ я уже молчу.
Без декомпозиции кортежей использовать их в шарпе просто противно. Казалось бы сделай:
И будет людям счастье. Не уж то в Розлине такое долго залудить?
VD>И будет людям счастье. Не уж то в Розлине такое долго залудить?
Говорят, долго. Хорошо хоть прямо не посылают, как раньше. Хотя, казалось бы, при наличии первичного конструктора и определенных ограничениях на внутренности уже никаких discriminated unions добавлять в язык не нужно, связь между параметрами и свойствами и так формально определена. Но, пока, увы.
AVK>Говорят, долго. Хорошо хоть прямо не посылают, как раньше.
Это — да. Это большой пробгресс. Глядишь к 8-ке таки урезанный ПМ выкатят, как в Котлине. И на шарпе можно будет программировать без мата вырывания волос на заднице.
AVK>Хотя, казалось бы, при наличии первичного конструктора и определенных ограничениях на внутренности уже никаких discriminated unions добавлять в язык не нужно, связь между параметрами и свойствами и так формально определена. Но, пока, увы.
Тут две проблемы. Одна, как ты верно заметил, связь между полями и параметрами конструктора. Вторая — это описание фиксированных иерархий.
Дело в том, что основной проблемой ПМ по классам является проблема неучтенных расширений (подтипов). Написал ты проверку, а потом добавил еще класс (возможно в другой сборке) и вот у тебя уже потенциальная ошибка в рантайме. Замкнутость алгебраических типов дает контроль над этим делом. Но тут можно sealed использовать. Кривовато, но работать будет.
А вообще, ПМ прекрасно работает и без соответствия параметров и полей. Получается чуть более громоздко, но все же удобнее ифов.
VD>Без декомпозиции кортежей использовать их в шарпе просто противно. Казалось бы сделай:
VD>
А зачем это нужно в таком виде? Все равно ведь непонятно, что в результате вернется. Лучше уж в специальную структурку завернуть результат.
Я бы предпочел, чтобы из анонимных типов можно было результат функции формировать, типа
ЕА>А зачем это нужно в таком виде? Все равно ведь непонятно, что в результате вернется. Лучше уж в специальную структурку завернуть результат.
ЕА>Я бы предпочел, чтобы из анонимных типов можно было результат функции формировать, типа
ЕА>
А как знать что внутри при вызове метода ?
Уже сейчас можно вернуть object/dynamic и вперед.
ЕА>А зачем это нужно в таком виде? Все равно ведь непонятно, что в результате вернется.
Непонятно это только теоретикам. У практиков проблем с пониманием не возникает.
ЕА>Лучше уж в специальную структурку завернуть результат.
Одно другого не отменяет. Иногда нужно по быстрому кортеж сваять, иногда нужно ясности придать, тут уже записи (описываемые анонимные типы) рулят.
ЕА>Я бы предпочел, чтобы из анонимных типов можно было результат функции формировать, типа
ЕА>
Это не разумное предложение. Оно быстро сломает интелисенс в больших проектах. В методе может быть 100500 выражений, и методов может быть 100500. Для вывода типов придется протипизировать все их тела. А это самая долгая операция. Решарпер даже не парсит тела методов до того как пользователь к ним не обратится. А ты предлагаешь их все типизировать.
Правильное решение для языка с хорошей поддержкой IDE будет возможность декларировать анонимные типы (превращение их в записи):
А>>>//read only auto-properties —
А>>>public int X { get; } = x;
_NN>>А как это работает ?
_NN>>Что означает "= x" ? Это инициализация или имя переменной ?
J>x в данном случае — это поле. Обрати внимание на primary constructor выше, скорее всего как F#, его параметры в поля преобразуются.
Вопрос был не в том, что такое "x", а в том является ли это именем для поля содержащего значение свойства, или "x" — это произвольное инициализирующее значение. Думаю, второе.
VD>Вопрос был не в том, что такое "x", а в том является ли это именем для поля содержащего значение свойства, или "x" — это произвольное инициализирующее значение. Думаю, второе.
Это испорченный телефон. Исходный пример такой:
А>>//read only auto-properties —
А>>public int X { get; } = x;
_NN>А как это работает ?
_NN>Что означает "= x" ? Это инициализация или имя переменной ?
Это инициализация скрытого поля соответствующего авто-свойству. Может быть любым выражением, разрешённым в инициализаторах полей. Выполняется при создании объекта.
_NN>Хотя наверное только из конструктора выводит, или как в Nemerle где может вывести из использования ?
Только из аргументов конструктора.
А>>//inline declarations for out params —
А>>public void Foo(out var x, out var y) { }
_NN>На мой взгляд как раз в публичных методах, которые являются контрактом класса, как раз не нужен вывод типов.
Это автор блога что-то намудрил. Предполагается разрешить такой синтаксис при вызовах методов с out-параметрами, а не при их декларации.
N>Это автор блога что-то намудрил. Предполагается разрешить такой синтаксис при вызовах методов с out-параметрами, а не при их декларации.
А когда будет что нибудь более официальное на этот счет? И будут ли какие то более интересные фичи, или это весь список нововведений?
А>А когда будет что нибудь более официальное на этот счет? И будут ли какие то более интересные фичи, или это весь список нововведений?
Пока что это список идей для гипотетических будущих версий C#. Некоторые из этих идей прототипировались, однако не нужно воспринимать пару слайдов на конференции как официальное объявление новых фич или как обязательство реализовать их в ближайшей следующей версии. Скорее, это приглашение к неформальной дискуссии, чтобы лучше понять, в чём нуждаются разработчики.
N>Скорее, это приглашение к неформальной дискуссии, чтобы лучше понять, в чём нуждаются разработчики.
Скажи честно, у тебя же у самого руки по локоть в
кровиAST Розлина. Неужели ты всё ещё не нуждаешься в паттерн-матчинге? ПМ ведь вам самим сэкономил бы тонны кода.N>Пока что это список идей для гипотетических будущих версий C#. Некоторые из этих идей прототипировались, однако не нужно воспринимать пару слайдов на конференции как официальное объявление новых фич или как обязательство реализовать их в ближайшей следующей версии. Скорее, это приглашение к неформальной дискуссии, чтобы лучше понять, в чём нуждаются разработчики.
Что тут дискуритровать? Все эти "идеи" сто лет как реализованы в куче языков и используются на практике. Все они зарекомендовали себя очень хорошо.
Я вот только не понял, что за фигня этот ваш "=>" синтаксис при объявлении членов. Это чтобы блок с return-ом не писать?
Если да, то решение спорное. Люди для этого сто лет как используют "=".
VD>Я вот только не понял, что за фигня этот ваш "=>" синтаксис при объявлении членов. Это чтобы блок с return-ом не писать?
Да. Методов это тоже касается.
VD>Если да, то решение спорное. Люди для этого сто лет как используют "=".
Конфликтует с инициализацией.
VD>>Если да, то решение спорное. Люди для этого сто лет как используют "=".
AVK>Конфликтует с инициализацией.
Этот вариант, заметь, еще и тучу вопросов вызывает.
А меж тем все вроде как довольно просто.
Для полей этой проблемы не стоит, так как они только инициализируются.
Для свойств можно использовать синтаксис:
А для методов привычный "=":
VD>Я вот только не понял, что за фигня этот ваш "=>" синтаксис при объявлении членов. Это чтобы блок с return-ом не писать?
VD>Если да, то решение спорное. Люди для этого сто лет как используют "=".
Да, C# это не Немерле и никогда, слава богу, им не будет.
В С# с первой версии = для присваивания. => уже используется для лямбд, что бы блок с ретурном не писать. Так что всё очевидно
I>Да, C# это не Немерле и никогда, слава богу, им не будет.
I>В С# с первой версии = для присваивания. => уже используется для лямбд, что бы блок с ретурном не писать. Так что всё очевидно
Для тебя. Но тут дело в тебе.
А>>>//inline declarations for out params —
А>>>public void Foo(out var x, out var y) { }
_NN>>На мой взгляд как раз в публичных методах, которые являются контрактом класса, как раз не нужен вывод типов.
N>Это автор блога что-то намудрил. Предполагается разрешить такой синтаксис при вызовах методов с out-параметрами, а не при их декларации.
Правильно. По мне так дальше нужно идти, не только облегчить работу с out-параметрами, но еще и максимально усложнить работу с туплами. Чтоб даже мысли не возникало их использовать.
J>Правильно. По мне так дальше нужно идти, не только облегчить работу с out-параметрами, но еще и максимально усложнить работу с туплами. Чтоб даже мысли не возникало их использовать.
Они именно так и поступают.
На банальную декомпозицию кортежей у них еще 10 лет уйдет (прошлые ушли на оператор ?. и прочие приятные рюшечки). Хорошо что хоть что-то тырят из правильных идей правильных языков.
А>>//inline declarations for out params —
А>>public void Foo(out var x, out var y) { }
_NN>Практикуют программирование на 'out' типах ?
_NN>Не проще ли кортежи добавить в язык ?
Проще, но хуже. У out-аргументов кроме типов есть ещё имена. У членов кортежа только типы.
Поэтому если метод возвращает два значения одного или близких типов, то при использовании двух out аргументов метод можно использовать, не заглядывая в документацию, а только взглянув на прототип. При использовании же кортежа, из прототипа метода уже не следует, где какой результат.
P.S. Понятно, что для (x,y) координат стоит завести класс или структуру (потому шо если алгоритм работает с геометрией то эти 2 значения постоянно передаются вместе + у них куча общей логики).
Однако бывают такие функции, результат которых бессмысленно оборачивать в класс/структуру. Например Math.DivRem из таких.
К>Проще, но хуже. У out-аргументов кроме типов есть ещё имена. У членов кортежа только типы.
К>Поэтому если метод возвращает два значения одного или близких типов, то при использовании двух out аргументов метод можно использовать, не заглядывая в документацию, а только взглянув на прототип.
Практика использования кортежей в языках, где они изначально поддерживаются, показывают одну особенность: их крайне редко их выставляют в публичный интерфейс.
К>Проще, но хуже. У out-аргументов кроме типов есть ещё имена. У членов кортежа только типы.
На то есть записи. Это как анонимные типы, но которые можно из методов возвращать.
А>>//read only auto-properties —
А>>public int X { get; } = x;
_NN>А как это работает ?
_NN>Что означает "= x" ? Это инициализация или имя переменной ?
Это параметр primary constructor. Который в предыдущем примере.
А>>public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
_NN>Проще разрешить выражения и убрать 'return', тогда не нужно ничего придумывать и использовать обычные свойства и методы.
Это сломает совместимость. Впрочем, кое что на эту тему, возможно, будет:
А>>//params for enumerables —
А>>public Point Average(params IEnumerable<Point> points) { }
_NN>Я так понимаю для этого нужно менять рантайм. Верно ?
Нет. params это синтаксический сахар, рантайм менять не нужно.
А>>if (points?.FirstOrDefault()?.X ?? -1) { }
_NN>Полезная фича, давно реализуемая в других языках.
Вот только синтаксис ...
_NN>Хотя наверное только из конструктора выводит
Да.
А>>//inline declarations for out params —
А>>public void Foo(out var x, out var y) { }
_NN>Практикуют программирование на 'out' типах ?
Упрощают его.
_NN>Не проще ли кортежи добавить в язык ?
Нет.
_NN>На мой взгляд как раз в публичных методах, которые являются контрактом класса, как раз не нужен вывод типов.
Это испорченный телефон. На самом деле правильный вариант такой:
AVK>Это испорченный телефон. На самом деле правильный вариант такой:
AVK>
Как соотносятся x слева и справа от оператора присваивания?
J>Как соотносятся x слева и справа от оператора присваивания?
Никак.
А>>>public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
_NN>>Проще разрешить выражения и убрать 'return', тогда не нужно ничего придумывать и использовать обычные свойства и методы.
AVK>Это сломает совместимость. Впрочем, кое что на эту тему, возможно, будет:
AVK>
Можно тогда добавить какой-нибудь префикс типа
AVK>Это испорченный телефон. На самом деле правильный вариант такой:
AVK>
Т.е. объявление переменной прямо из вызова метода ?
Может просто добавить вывод типов из использования для out.
Скажем, Nemerle:
_NN>Можно тогда добавить какой-нибудь префикс
Вот так языки и превращаются в какашку
AVK>>Это испорченный телефон. На самом деле правильный вариант такой:
AVK>>
_NN>Т.е. объявление переменной прямо из вызова метода ?
Exactly. Declaration expression называется.
_NN>Может просто добавить вывод типов из использования для out.
_NN>Скажем, Nemerle:
_NN>
Зачем? Смысл этой конструкции как раз в том чтобы предварительно ничего не декларировать.
AVK>Зачем? Смысл этой конструкции как раз в том чтобы предварительно ничего не декларировать.
Затем, что становится очевидной область видимости таких переменных.
H>Затем, что становится очевидной область видимости таких переменных.
Вывода типов по имспользованию в C# все равно не будет.
AVK>Вывода типов по имспользованию в C# все равно не будет.
Да, бдудет. Лет эдак через 15-20.
Я закладку на это твое сообщение поставил. Через 15 лет обсудим (если живы будем).
Вывод типов по использованию — это очень удобно. Единственная проблема — сложность алгоритмов. Но это проблема времени, а не идеологическая. А значит рано или поздно ее устранят.
_NN>>Может просто добавить вывод типов из использования для out.
_NN>>Скажем, Nemerle:
_NN>>
AVK>Зачем? Смысл этой конструкции как раз в том чтобы предварительно ничего не декларировать.
Не всегда переменная нужна для out-параметров. Часто она просто по разному инициализируется в разных подветках if-ов и т.п. В шарпе очень задалбывает, что в основном можно писать var, но иногда нужно по приседать (описать тип явно).
VD>Не всегда переменная нужна для out-параметров. Часто она просто по разному инициализируется в разных подветках if-ов и т.п. В шарпе очень задалбывает, что в основном можно писать var, но иногда нужно по приседать (описать тип явно).
Это понятно, но тут предлагается это вместо declaration expression.
AVK>Это понятно, но тут предлагается это вместо declaration expression.
Вот я и говорю, что одно другому не мешает. Понятно, что крутой вывод типов по использованию МС сейчас не потяент. Но лет за 10 они вполне его могут сделать на должном уровне.
_NN>Может просто добавить вывод типов из использования для out.
_NN>Скажем, Nemerle:
_NN>
Вывод типов полезен сам по себе. Но для out-параметров, действительно удобно было бы объявлять переменные прямо в параметрах. Тогда можно было бы писать как-то так:
AVK>Это сломает совместимость. Впрочем, кое что на эту тему, возможно, будет:
AVK>
А зачем в круглых то скобках, а не в фигурных?
VD>А зачем в круглых то скобках, а не в фигурных?
Это не финальный синтаксис.
А>>public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
_NN>Проще разрешить выражения и убрать 'return', тогда не нужно ничего придумывать и использовать обычные свойства и методы.
Это первый шаг в сторону "все есть выражение". Похоже, что вводить такое сразу по многим причинам (в том числе неприятие разработчиков) тяжело. Это легкий вариант.
Z>Здравствуйте, _NN_, Вы писали:
А>>>public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
_NN>>Проще разрешить выражения и убрать 'return', тогда не нужно ничего придумывать и использовать обычные свойства и методы.
Z>Это первый шаг в сторону "все есть выражение". Похоже, что вводить такое сразу по многим причинам (в том числе неприятие разработчиков) тяжело. Это легкий вариант.
Тогда это выглядит довольно разумно.
Может сделать и следующий шаг ?
_NN>
И что это должно означать?
AVK>Здравствуйте, _NN_, Вы писали:
_NN>>
AVK>И что это должно означать?
Что тело 'then' и 'else' будет выражением а не просто блоком кода, т.е. что-то возвращает и тогда это можно будет использовать справа от присваивания
_NN>Что тело 'then' и 'else' будет выражением а не просто блоком кода, т.е. что-то возвращает и тогда это можно будет использовать справа от присваивания
И чем это отличается от "true?1:2" кроме лишней писанины?
AVK>Здравствуйте, _NN_, Вы писали:
_NN>>Что тело 'then' и 'else' будет выражением а не просто блоком кода, т.е. что-то возвращает и тогда это можно будет использовать справа от присваивания
AVK>И чем это отличается от "true?1:2" кроме лишней писанины?
Я так понял на самом деле NN таки хочет вот этой фичи
http://rsdn.ru/forum/dotnet/5399449.1
ну и тогда можно будет писать так:
AVK>И чем это отличается от "true?1:2" кроме лишней писанины?
Очевидно, тем что применимо к любой конструкции. А ?: — это хардкод.
Z>Это первый шаг в сторону "все есть выражение". Похоже, что вводить такое сразу по многим причинам (в том числе неприятие разработчиков) тяжело. Это легкий вариант.
Дело не в неприятии разработчиков, дело в том что C# не Немерле, и туда никто ничего не добавляет просто потому что кому то захотелось (если, конечно, захотелось не Андерсу ). Конкретно declaration expressions придумали, потому что не получается качественно добавить кортежи. Ну а фокусы типоа того, что я показал — просто побочные эффекты. Из той же оперы, кстати (оператор as is ):
Но таки да, дальняя цель — как можно больше конструкций сделать выражениями. Некоторые, к примеру, жаловались что нет statement формы для оператора ?:, теперь вот она есть. Еще обсуждал с Мэдсом expression форму switch (он, сктати, сказал, что и сишную бредятину с break надо выкидывать, и что как в VB позволить условия сложные писать в кейсах) — вроде бы есть какие то эксперименты (просьба воспринимать это как мои домыслы, потому что NDA) с все тем же оператором ?:, у которого может быть несколько вариантов как в switch.
Z>>Это первый шаг в сторону "все есть выражение". Похоже, что вводить такое сразу по многим причинам (в том числе неприятие разработчиков) тяжело. Это легкий вариант.
AVK>Дело не в неприятии разработчиков, дело в том что C# не Немерле, и туда никто ничего не добавляет просто потому что кому то захотелось (если, конечно, захотелось не Андерсу ).
Я и не называл это главной причиной. На текущий синтаксис это ляжет плохо, слишком много изменений, в том числе и ломающих обратную совместимость, для одной версии придется внести. Все равно изменения должны ложиться на привычный базис.
AVK>Конкретно declaration expressions придумали, потому что не получается качественно добавить кортежи.
Они как-то связаны или просто остались свободные ресурсы?
AVK>Ну а фокусы типоа того, что я показал — просто побочные эффекты. Из той же оперы, кстати (оператор as is ):
AVK>
Это 6.0 или дальнейшие планы?
AVK>Но таки да, дальняя цель — как можно больше конструкций сделать выражениями. Некоторые, к примеру, жаловались что нет statement формы для оператора ?:, теперь вот она есть. Еще обсуждал с Мэдсом expression форму switch (он, сктати, сказал, что и сишную бредятину с break надо выкидывать, и что как в VB позволить условия сложные писать в кейсах) — вроде бы есть какие то эксперименты (просьба воспринимать это как мои домыслы, потому что NDA) с все тем же оператором ?:, у которого может быть несколько вариантов как в switch.
switch конечно самое вкусное, но сразу же захочется try/catch и using. Ну и иммутабельные переменные на закуску, ведь в нормальном коде большинство их станет именно такими.
AVK>>Конкретно declaration expressions придумали, потому что не получается качественно добавить кортежи.
Z>Они как-то связаны или просто остались свободные ресурсы?
Связаны конечно. Туплы, применительно к шарпу, в основном, могут решить две проблемы:
1) Инлайн декларация сложного возвращаемого результата.
2) Хранение составных типов в нелокальных контейнерах.
DE решает только первую проблему, но решает ее лучше туплов, потому что у out параметров есть имена. Ну и собственно DE заменяет операцию распаковки тупла в локальные переменные.
Z>Это 6.0 или дальнейшие планы?
Я так думаю (ну ты понял, да?) что 6.0. Но пока, в отличие от первичных конструкторов и новых литералов, это все писями по воде виляно.
Z>switch конечно самое вкусное, но сразу же захочется try/catch и using.
Ну, цель то заявлена именно в разумно полном покрытии всех конструкций. Просто свитч больше всего напрягает лично меня.
Z> Ну и иммутабельные переменные на закуску, ведь в нормальном коде большинство их станет именно такими.
В локальном контексте не так критично. Я только обратил внимание, что неплохо бы добавить вывод типов для локальных констант. Можно заодно расширить их семантику до ro переменных, все равно наружу оно не смотрит и в сборке не фиксируется никак.
AVK>DE решает только первую проблему, но решает ее лучше туплов, потому что у out параметров есть имена. Ну и собственно DE заменяет операцию распаковки тупла в локальные переменные.
Хреново он ее решает. Неудобно. Лучше бы довели до ума анонимные типы. Сделали бы синтаксисх их декларации по месту, как у записей в ML-е. Например:
AVK>В локальном контексте не так критично. Я только обратил внимание, что неплохо бы добавить вывод типов для локальных констант. Можно заодно расширить их семантику до ro переменных, все равно наружу оно не смотрит и в сборке не фиксируется никак.
А я как сейчас помню восторженную презентацию C# (1.0) в которой рассказывалось о необходимости указывать тип у констант, как о невероятном достоинстве.
VD>Хреново он ее решает. Неудобно. Лучше бы довели до ума анонимные типы. Сделали бы синтаксисх их декларации по месту
Это было бы, вне всяких сомнений, лучше.
VD>Хреново он ее решает. Неудобно. Лучше бы довели до ума анонимные типы. Сделали бы синтаксисх их декларации по месту, как у записей в ML-е. Например:
VD>
А такие типы между сборок должны шарится?
AVK>Дело не в неприятии разработчиков, дело в том что C# не Немерле,
+1
И это его главный недостаток.
А главное достоинство C#-а — это ReSharper!
Z>Это первый шаг в сторону "все есть выражение". Похоже, что вводить такое сразу по многим причинам (в том числе неприятие разработчиков) тяжело. Это легкий вариант.
Скорее это шаг в сторону. Если бы хотели сделать "все есть выражение", то не стали бы городить отдельный синтаксис для инициализации членов, а сделали бы универсальное решение.
VD>Скорее это шаг в сторону. Если бы хотели сделать "все есть выражение", то не стали бы городить отдельный синтаксис для инициализации членов, а сделали бы универсальное решение.
Там не только инициализация, но и тело метода может быть.
Z>Там не только инициализация, но и тело метода может быть.
Ну, вот и нужно было для тела выбрать "=", а инициализацию как-то по другому сделать.
Собственно мы так и сделали. NN по началу тоже хотел вариант
выбрать. Но мы подумали и решили, что это чревато проблемами.
А>>//read only auto-properties —
А>>public int X { get; } = x;
_NN>А как это работает ?
_NN>Что означает "= x" ? Это инициализация или имя переменной ?
Инициализация.
_NN>Можно ли как в Nemerle ?
Ага:
_NN>
А>>//params for enumerables —
А>>public Point Average(params IEnumerable<Point> points) { }
_NN>Я так понимаю для этого нужно менять рантайм. Верно ?
Зачем? Это чисто компиляторная фича. Просто вместо массива можно указать IEnumerable в params-методах.
А>>//monadic null checking —
А>>if (points?.FirstOrDefault()?.X ?? -1) { }
_NN>Полезная фича, давно реализуемая в других языках.
Можно подумать, что все остальные фичи в других языках не реализованы, или реализованы недавно .
А>>//constructor type parameter inference —
А>>var t = new Tuple(1,2); // infers Tuple<T1, T2>
_NN>Ну наконец.
_NN>Хотя наверное только из конструктора выводит, или как в Nemerle где может вывести из использования ?
Конечно, первое.
А>>//inline declarations for out params —
А>>public void Foo(out var x, out var y) { }
_NN>Практикуют программирование на 'out' типах ?
_NN>Не проще ли кортежи добавить в язык ?
Гы.
_NN>На мой взгляд как раз в публичных методах, которые являются контрактом класса, как раз не нужен вывод типов.
+1 И даже вреден (для производительности IDE). Может автор ошибся и там нельзя var использовать?
А>http://adamralph.com/2013/12/06/ndc-diary-day-3/
А>
А>Имхо, какой то хоть и полезный но хлам.
у Scala передрали.
G>у Scala передрали.
Джаве тоже пора что-нибудь передрать. Хотя бы у Шарпа.
GH>Джаве тоже пора что-нибудь передрать. Хотя бы у Шарпа.
Java 8.
Или вам что-то конкретное нужно ?
А>//primary constructors —
А>public class Point(int x, int y) { }
Кто-нибудь может объяснить, что это? А то все читают с таким видом, будто это есть во всех языках и только c# наконец до этого докатился!
А>//static type using statements —
А>using System.Math;
Это как в Немерле — импорт класса и вызов в коде статических методов без указания класса?
А>//monadic null checking —
А>if (points?.FirstOrDefault()?.X ?? -1) { }
Больше говнокода! Даёшь жабоскрипт!
Мрак, если откровенно.
А что там народ заикался про множественный return? Разве это возможно? (без хаков) Мой эксперимент на MSIL показал, что возврат из функции с более чем одним элементом на стеке сразу разрывает на куски. Т.е. "напрямую" не получится, значит опять индусские дуроломы прикрутят на изоленте hidden class, который будет прятать в себе массив возвращаемых значений.
А>>//primary constructors —
А>>public class Point(int x, int y) { }
А>Кто-нибудь может объяснить, что это? А то все читают с таким видом, будто это есть во всех языках и только c# наконец до этого докатился!
Синтаксический сахар. Транслируется в такое:
А>>//static type using statements —
А>>using System.Math;
А>Это как в Немерле — импорт класса и вызов в коде статических методов без указания класса?
Да. Причем для extension методов тоже будет работать.
А>>//monadic null checking —
А>>if (points?.FirstOrDefault()?.X ?? -1) { }
А>Больше говнокода! Даёшь жабоскрипт!
А>Мрак, если откровенно.
Мрак в чем? Если в синтаксисе, то это не окончательный вариант.
А>А что там народ заикался про множественный return? Разве это возможно?
Это ты о чем вообще?
А>>//primary constructors —
А>>public class Point(int x, int y) { }
А>Кто-нибудь может объяснить, что это? А то все читают с таким видом, будто это есть во всех языках и только c# наконец до этого докатился!
Это аналогично немерловой макре Record, но несколько более гибко, так как можно реализовать логику в кострукторе.
Фича взята из ML-семейсва. Есть в Scala, F#...
Параметры такого конструктора автоматически превращаются в поля класса. Такой конструктор может быть только один.
Если реализуют все грамотно, то тело класса при этом станет единым "скриптом" инициализации (заменой тела конструктора).
А>>using System.Math;
А>Это как в Немерле — импорт класса и вызов в коде статических методов без указания класса?
Да.
А>>//monadic null checking —
А>>if (points?.FirstOrDefault()?.X ?? -1) { }
А>Больше говнокода! Даёшь жабоскрипт!
А>Мрак, если откровенно.
Не скажи. Мы это в Nemerle из Groovy уже дано передрали. Очень удобно когда нужно делать много проверок на null.
Код сокращается в разы. Так что говнокод скорее без этого оператора.
Его суть очень проста. Это точка с проверкой на нул. Если выражение перед ?. вычислится в null, то выражение идущее за ?. не будет вычисляться, а будет возвращен null.
Это повзоволяет создать аналог множественного доступа к членам, но если одни из членов будет null, вместо вылета по исключению будет возвращен null, который нужно будет проверить ровно один раз.
А>А что там народ заикался про множественный return? Разве это возможно? (без хаков) Мой эксперимент на MSIL показал, что возврат из функции с более чем одним элементом на стеке сразу разрывает на куски. Т.е. "напрямую" не получится, значит опять индусские дуроломы прикрутят на изоленте hidden class, который будет прятать в себе массив возвращаемых значений.
Для этого придуманы кортежи и записи. Но до них МС будет доходить следущие 10 лет.
VD>Это аналогично немерловой макре Record, но несколько более гибко, так как можно реализовать логику в кострукторе.
Ты имеешь в виду другой конструктор?
Z>Ты имеешь в виду другой конструктор?
Я так понял, что тот же самый:
Речь шла о фиче:
А>>//primary constructors —
А>>public class Point(int x, int y) { }
Влад сказал, что это аналог немерловой макры Record.
Насколько я понимаю, в primary constructor, логику реализовать не получится. Вот и хотел уточнить, что он имел в виду.
Z>Насколько я понимаю, в primary constructor, логику реализовать не получится.
ну вот это как раз большой вопрос. ПОтому что в том же F# как раз можно реализовать логику в праймари конструкторе. http://msdn.microsoft.com/en-us/library/dd233192.aspx
Z>>Насколько я понимаю, в primary constructor, логику реализовать не получится.
J>ну вот это как раз большой вопрос. ПОтому что в том же F# как раз можно реализовать логику в праймари конструкторе. http://msdn.microsoft.com/en-us/library/dd233192.aspx
Есть. И не только в F#. Но представленный синтаксис для C# выглядит так, как будто нельзя.
S>Я так понял, что тот же самый:
S>
Не не не, так нельзя.
А>Имхо, какой то хоть и полезный но хлам.
Фокус этого релиза — новый компилятор и language service в студии, глобальных фич ожидать не стоит. И это, на самом деле, хорошо, потому что ели бы были глобальные фичи, мелочи бы опять остались нереализоованными.
А>//constructor type parameter inference —
А>var t = new Tuple(1,2); // infers Tuple<T1, T2>
А как насчет "частичного" вывода типов??
что нить типа такого:
TResult Method<TArg, TResult>(TArg arg) { ... }
var s = Method<_, string>(10); // TArg вывелось как int
А>http://adamralph.com/2013/12/06/ndc-diary-day-3/
А>
мне кажется, что это одно и тоже.
зачем вводить синтаксис public int X { get; } = x если и так можно будет написать public int X => x; ?
J>мне кажется, что это одно и тоже.
Кажется.
J>зачем вводить синтаксис public int X { get; } = x если и так можно будет написать public int X => x; ?
Потому что в первом случае это автосвойство, инициализируемое в конструкторе один раз, а во втором — вычисляемое при каждом обращении свойство.
J>>зачем вводить синтаксис public int X { get; } = x если и так можно будет написать public int X => x; ?
AVK>Потому что в первом случае это автосвойство, инициализируемое в конструкторе один раз, а во втором — вычисляемое при каждом обращении свойство.
Что-то пугает меня этот зоопарк. 4 варианта для описания свойства... зачем писать
?
S>Здравствуйте, AndrewVK, Вы писали:
J>>>зачем вводить синтаксис public int X { get; } = x если и так можно будет написать public int X => x; ?
AVK>>Потому что в первом случае это автосвойство, инициализируемое в конструкторе один раз, а во втором — вычисляемое при каждом обращении свойство.
S>Что-то пугает меня этот зоопарк. 4 варианта для описания свойства... зачем писать
S>
S>?
Это разное
==>
Имеем значение по умолчанию, но в конструкторе можно подправить.
_NN>Это разное
_NN>Имеем значение по умолчанию, но в конструкторе можно подправить.
Ага, про поле в примере я забыл. Один фиг, синтаксис с "= x" от этого лучше не стал. Почему "= someField" означает инициализацию поля и при этом поле readonly? Даже первое пришедшее в голову
и то логичнее смотрится
Понятно, что это пока только идеи, а не то, что будет к релизу. Но явно выпадающие из привычного стиля шарпа вещи точно без обоснования вводить не следует.
S>и то логичнее смотрится
А зачем нужно задавать имя для поля ?
Если оно только для чтения все равно кроме конструктора менять нигде нельзя.
Достаточно, чтобы компилятор сам его подставлял в конструкторе.
S>Понятно, что это пока только идеи, а не то, что будет к релизу. Но явно выпадающие из привычного стиля шарпа вещи точно без обоснования вводить не следует.
Например Nemerle: так и так
S>>и то логичнее смотрится
_NN>А зачем нужно задавать имя для поля ?
1. В исходном синтаксисе можно
2. Для использования поля напрямую (например через ref) и навешивания атрибутов на поле.
Хотя по-моему в обоих пунктах давно пора переключиться на обычные поля и не мучать мозг.
_NN>Например Nemerle: так и так
Ага, тоже неплохо.
S>Что-то пугает меня этот зоопарк. 4 варианта для описания свойства... зачем писать
S>
S>?
Ты уж полностью раскрывай и в эквивалентный код:
Во-втором варианте писанины несколько побольше, не находишь?
Судя по всему, у дизайнеров языка нет цели — они сами не знают, к чему стремятся и что оптимизируют (это можно сказать не только про C#, но и про многие другие языки, это какой-то бич всей области разработки языков). Пока что курс намечается на то, что язык будет все более сложным для изучения и чтения и будет превращаться в концептуально-синтаксическую помойку, что не может не огорчать, так как C# первое время подавал пример того, как надо подходить к разработке новых языков.
Мне что-то кажется, что этот уклон в сторону примешивания фич и синтаксиса из функциональных языков идет от Липперта, а не от Хейлсберга. Возможно, этим двум людям вообще стоило бы разрабатывать два разных языка.
А>Мне что-то кажется, что этот уклон в сторону примешивания фич и синтаксиса из функциональных языков идет от Липперта, а не от Хейлсберга. Возможно, этим двум людям вообще стоило бы разрабатывать два разных языка.
Липперт уже год как не работает в MS.
А>Мне что-то кажется, что этот уклон в сторону примешивания фич и синтаксиса из функциональных языков идет от Липперта
Липперт уже в МС не работает.
А>а не от Хейлсберга
Ну, все что здесь описано идет таки не от него, хотя он, разумеется, участвует в их разработке и право вето у него тоже имеется. От него идет кое какая другая фича, но ее по ссылке в стартовом сообщении не описали, а я про нее рассказать пока не могу, NDA.
А что минус-то поставил. С чем не согласен?
А>А что минус-то поставил. С чем не согласен?
С первым утверждением.
А>Пока что курс намечается на то, что язык будет все более сложным для изучения и чтения и будет превращаться в концептуально-синтаксическую помойку.
Я думаю тебе следует провести эксперимент и пописать сейчас на C# v1.0. После этого должно прийти понимание, в какой стороне находится помойка.
Это если ты уже плотно используешь в работе лямбды, linq, вывод типов. Если еще не используешь, просто проигнорируй мое сообщение.
Z>Это если ты уже плотно используешь в работе лямбды, linq, вывод типов. Если еще не используешь, просто проигнорируй мое сообщение.
Я вообще без лямбд и линка код не пишу. Не for-ы же писать? Дело не в этом, а в концептуальной стройности языка и сложности его синтаксиса.
Например, язык C — концептуально чист (тем, что прост как дверь), но программировать на нем мне совершенно не нравится из-за его ограниченности и кучи тупой ручной работы, Хаскель — тоже относительно концептуально чист, но программировать на нем весело и приятно.
Но функционально-императивный кентавр, в которого превращается C#, у меня вызывает сомнения. По-моему, затаскивать в императивный C-подобный язык синтаксический сахар из ML-языков — это уже перебор. Все-таки, автору языка надо сопоставлять преимущества фич языка с растущей сложностью и поддерживать общую концепцию. А то получится невероятно сложный винегрет из всех языков, в котором одно и то же можно будет сделать настолько разным кодом, что нельзя даже будет подумать, что это написано на одном языке.
Все-таки, неплохо бы авторам языков начать смотреть в реальные проблемы программирования, а не делать из языков швейцарские ножи, занимаясь развитием ради развития.
Неплохо бы понимать, что каждая финтифлюшка усложняет язык, повышает порог вхождения и усложняет сопровождение кода. То, что легко писать — не всегда легко читать и изменять.
Последние изменения в C# наталкивают на мысль, что авторы языка несколько забылись. Это ведь очень легко — начать пихать в язык фичи.
Проблема в том, что, похоже, никто даже не пытается определить, какие параметры в языках программирования следует оптимизировать. Я сильно сомневаюсь, что количество фич и объем синтаксического сахара — это те параметры, которые сильно влияют на производительность разработки всего проекта в перспективе.
А>Все-таки, неплохо бы авторам языков начать смотреть в реальные проблемы программирования
Именно это они и делают. Но хотелось бы услышать про то, какие ты проблемы считаешь реальными.
А>Но функционально-императивный кентавр, в которого превращается C#, у меня вызывает сомнения. По-моему, затаскивать в императивный C-подобный язык синтаксический сахар из ML-языков — это уже перебор. Все-таки, автору языка надо сопоставлять преимущества фич языка с растущей сложностью и поддерживать общую концепцию. А то получится невероятно сложный винегрет из всех языков, в котором одно и то же можно будет сделать настолько разным кодом, что нельзя даже будет подумать, что это написано на одном языке.
Функционально-императивным кентавром он стал после введения лямбд. Те, кому это не по нраву не должны использовать лямбды, а ты утверждаешь, что к ним не относишься.
Синтаксический сахар из ML протаскивают, чтобы потом не было мучительно больно вводить другой, очень серьезный и нужный принцип. Который называется — "все есть выражение".
А>Все-таки, неплохо бы авторам языков начать смотреть в реальные проблемы программирования, а не делать из языков швейцарские ножи, занимаясь развитием ради развития.
Что за реальные проблемы программирования?
Z>Синтаксический сахар из ML протаскивают, чтобы потом не было мучительно больно вводить другой, очень серьезный и нужный принцип. Который называется — "все есть выражение".
Оффтопик, но я лично не очень понимаю, зачем и кому этот принцип нужен. Цикл — выражение? Ну это же тупо. А методы с побочными эффектами делать выражением я бы вообще запретил (понятно, тут речь уже не о C#).
ARK>Оффтопик, но я лично не очень понимаю, зачем и кому этот принцип нужен. Цикл — выражение? Ну это же тупо. А методы с побочными эффектами делать выражением я бы вообще запретил (понятно, тут речь уже не о C#).
Вызов метода с побочными эффектами это уже выражение, как-то живем с этим. Цикл можно рассмотреть, как частный случай выражения, который возвращает void. Это не тупее, чем отказ от разделения на function и procedure.
Z>Вызов метода с побочными эффектами это уже выражение, как-то живем с этим.
Ну, это ничего не значит. Много с чем живем, например с нуллабельными по умолчанию ссылками, что есть бред.
Z>Цикл можно рассмотреть, как частный случай выражения, который возвращает void. Это не тупее, чем отказ от разделения на function и procedure.
На мой взгляд, разделение концептуально гораздо чище.
ARK>Оффтопик, но я лично не очень понимаю, зачем и кому этот принцип нужен.
Этот принцип формирует правильную культуру ветвления алгоритма. Сводит к минимуму использование мутабельных переменных, а иммутабельные переменные это и не переменные вовсе, это символьное обозначение какого-то значения, которое мы получили где-то ранее. В таком коде сделать ошибку сложнее, а заметить проще, это большой плюс.
сравни:
Второй вариант о смысле кода говорит больше, чем первый. Во втором варианте сразу видно, что а может иметь два значения в зависимости от условия. В первом варианте мы только строим гипотезы в процессе чтения.
На закуску попробуй переписать код на языке, в котором using не является выражением:
Типы не важны, можешь взять любые, с которыми код скомпилируется.
Z>Этот принцип формирует правильную культуру ветвления алгоритма. Сводит к минимуму использование мутабельных переменных
Не понимаю, каким образом.
Z>В таком коде сделать ошибку сложнее, а заметить проще, это большой плюс.
По-моему, ровно наоборот. В выражении пропустить побочный эффект гораздо проще, чем когда он один гордо красуется на одной строке.
Z>Второй вариант о смысле кода говорит больше, чем первый. Во втором варианте сразу видно, что а может иметь два значения в зависимости от условия. В первом варианте мы только строим гипотезы в процессе чтения.
Это-то понятно, и наличие в языке if/switch в виде выражений исключительно полезно. А вот нафига циклы и процедуры в виде выражений?
Z>На закуску попробуй переписать код на языке, в котором using не является выражением:
Z>
Z>Типы не важны, можешь взять любые, с которыми код скомпилируется.
Z>Функционально-императивным кентавром он стал после введения лямбд.
И что такого принципиально нового добавили лямбды по сравнению с анонимными методами?
Функционально-императивным шарп делают не столько его фичи, сколько то как его используют, коммьюнити в том числе. Поэтому очень странно претензии предъявлять МС. Если бы с функциональщиной были какие то серьезные проблемы, она бы просто не использовалась бы особо.
AVK>И что такого принципиально нового добавили лямбды по сравнению с анонимными методами?
Это странный вопрос для человека который видит огромную разницу между Разером и Т4.
Синтаксис. Писать в функциональном стиле с анонимными методами очень некрасиво. Код получается громоздким.
VD>Это странный вопрос для человека который видит огромную разницу между Разером и Т4.
Между ними, мягко говоря, разницы побольше, чем между лямбдами и анонимными методами.
VD>Синтаксис. Писать в функциональном стиле с анонимными методами очень некрасиво. Код получается громоздким.
Код получается громоздким прежде всего не из-за анонимных типов, а из-за отсутствия вывода типов.
AVK>И что такого принципиально нового добавили лямбды по сравнению с анонимными методами?
Сахар, после которого их использование стало массовой практикой.
AVK>Функционально-императивным шарп делают не столько его фичи, сколько то как его используют, коммьюнити в том числе. Поэтому очень странно претензии предъявлять МС. Если бы с функциональщиной были какие то серьезные проблемы, она бы просто не использовалась бы особо.
Я тут с тобой полностью согласен и никаких претензий МС не предъявляю. Тебе показалось.
Z>Я тут с тобой полностью согласен и никаких претензий МС не предъявляю. Тебе показалось.
Мне не показалось, эта реплика для Анонима в основном предназначалась.
фичи вкусные вполне, хоть все больше и "сахарные"
DM>a есть хоть какая-то инфа когда его ждать?
Определенного ничего нет. Скорее всего выход новой студии будет приурочен к выходу Windows 8.2.