Z>Можно же сделать предупреждение, которое включается флагом компилятора. Это не проблема.
тогда уж делать атрибутом, который можно навесить на метод, класс, assembly. Если делать флагом, то не получится одновременно использовать и старый, и новый код.
Здравствуйте, DarkGray, Вы писали:
_>> .? может быть не очень удобным, если вместо значения default(T) нужно получить что-то другое, например int.MinValue;
DG>default(T) в operator .? — это всегда null (за исключением вырожденного случая для void)
DG>и соответственно, это выражение
_>> var x = A.?B.?C : int.MinValue;
DG>можно сделать через имеющийся operator ?? DG>
DG>var x = A.?B.?C ?? int.MinValue;
DG>
то есть ты хочешь, чтобы A.?B.?C вернуло Nullable<int> ??? Оно конечно понятно и логично, но что делать если С — ссылочный тип(object, например) ??
возвращать Nullable<C> если С struct и просто С, если С — ссылочный — это костыль, ИМХО. Нужен нормальный Maybe, работающий и для struct и для class. Но наличие одновременно и Nullable и Maybe — это тоже так себе решение...
Здравствуйте, Ziaw, Вы писали:
Z>Основная причина, это слишком большой шаг, его страшно делать.
На самом деле нет, почитайте Липперта. У него половина блога — как раз о вопросах "почему нет фичи X" и "по каким правилам мы добавляем новые возможности".
Почти всё, что добавлялось в шарп было:
1. Полезным для определённых сценариев (даже именованные параметры вполне полезны, особенно для интеропа с вордом).
2. Не дублировало имеющийся функционал, а дополняло его (автосвойства не отменили обычных свойств etc).
Не, есть конечно отдельные некрасивые моменты типа 100500 способов для объявления массива и пары delegate {} / () =>, но на практике они не мешают.
Напротив, чуть ли не половина фич в этой и параллельной ветке (в дотнетовском форуме) выглядит как-то так:
— запросы типа "я привык к XXX, тут всё не так, сделайте как там".
— фичи, которые будут неудобны на практике и про которые 1000развсё обжёвано.
— и шедевральные "тут прикольная фича есть, делать 5 минут, надо только немного поломать синтаксис/рантайм и выкинуть нафиг старый код чтобы под lin работало".
Не, ну блииин, ребят, у себя вы так же к пользователям относитесь — "мне удобно, если у кого что поломается — их проблемы"?
Если уж предлагать — начинайте с реальных сценариев использования.
The first reason is that doing so violates the functional programming principles that all the other sequence operators are based upon. Clearly the sole purpose of a call to this method is to cause side effects.
The purpose of an expression is to compute a value, not to cause a side effect. The purpose of a statement is to cause a side effect. The call site of this thing would look an awful lot like an expression (though, admittedly, since the method is void-returning, the expression could only be used in a “statement expression” context.)
Вот такое:
var x = ReadLine();
var y = "456";
var z = x ?? { y = "123"; Save(y); y;};
Console.WriteLine(y);
Это типа удобная фича?
Со всем прочим — то же самое. Тот же infoof, если его добавят, превратится в "а теперь то же самое, только для expression-ов, иначе неудобно указывать перегрузку.". Фишки из XXX будут конфликтовать с YYY. Always as expression породит тонну холиваров — писать ли return в методах вида
static int GetValueA() { GetValueB(); }
, что круче — ?: или if/else, почему нельзя сделать x = foreach(...) {} ?? 123 и т.д. и т.п.
Для экспериментов есть тонна других языков, зачем всё стаскивать в один?
Здравствуйте, Sinix, Вы писали:
S>На самом деле нет, почитайте Липперта. У него половина блога — как раз о вопросах "почему нет фичи X" и "по каким правилам мы добавляем новые возможности".
Липперта надо читать везде или только на stackowerflow? Я раньше читал его, но бросил, когда перестал делать ставку на один язык. Не могу сейчас уделять ему столько времени.
S>Почти всё, что добавлялось в шарп было: S>1. Полезным для определённых сценариев (даже именованные параметры вполне полезны, особенно для интеропа с вордом). S>2. Не дублировало имеющийся функционал, а дополняло его (автосвойства не отменили обычных свойств etc).
Предлагаю привести опровергающие примеры для предлагаемой фичи. Примеры, вроде "вот тут можно сделать как автосвойство, так и оставить обычное" не берем в рассчет, ок?
S>Не, ну блииин, ребят, у себя вы так же к пользователям относитесь — "мне удобно, если у кого что поломается — их проблемы"?
Вы сейчас точно ко мне обращаетесь? У кого и что сломается?
S>Если уж предлагать — начинайте с реальных сценариев использования.
Я думаю тут неглупые люди, которые не раз создавали не инициализированные переменные перед блоками using и try, к примеру. Часто эти блоки являются expression именно для инициализации именно этой переменной. Часто переменная остается не инициализированной по ошибке программиста.
S>конкретно про statement as expression: S>
S>The first reason is that doing so violates the functional programming principles that all the other sequence operators are based upon. Clearly the sole purpose of a call to this method is to cause side effects.
S>The purpose of an expression is to compute a value, not to cause a side effect. The purpose of a statement is to cause a side effect. The call site of this thing would look an awful lot like an expression (though, admittedly, since the method is void-returning, the expression could only be used in a “statement expression” context.)
Ну это религия. Я раньше был ярым поклонником этой точки зрения, но потом, как-то отошел от догм. Просто сейчас пишу на разных языках, на C# и JS ощутимо недостает этой фичи, в отличии от Ruby&CoffeeScript.
S>Вот такое: S>
S>var x = ReadLine();
S>var y = "456";
S>var z = x ?? { y = "123"; Save(y); y;};
S>Console.WriteLine(y);
S>
S>Это типа удобная фича?
Покажите мне хоть одну фичу из уже введенных в язык, с которой я не смогу создать подобный говнокод?
S>Со всем прочим — то же самое. Тот же infoof, если его добавят, превратится в "а теперь то же самое, только для expression-ов, иначе неудобно указывать перегрузку.". Фишки из XXX будут конфликтовать с YYY. Always as expression породит тонну холиваров — писать ли return в методах вида S>
S>static int GetValueA() { GetValueB(); }
S>
, что круче — ?: или if/else, почему нельзя сделать x = foreach(...) {} ?? 123 и т.д. и т.п.
Покажите мне хоть одну фичу из введенных в язык, по которой не было холивара на RSDN.
S>Для экспериментов есть тонна других языков, зачем всё стаскивать в один?
Это не эксперимент. Эта фича давно обкатана во множестве императивных языков. Ну и надо определиться, чего хочется, совершенно новых вещей или тех, что есть в других языках. А то я вижу претензии по обоим пунктам одновременно.
Здравствуйте, Ziaw, Вы писали:
Z>Липперта надо читать везде или только на stackowerflow? Я раньше читал его, но бросил, когда перестал делать ставку на один язык. Не могу сейчас уделять ему столько времени.
Я подписан на блоги (старый, новый), на SO за Липпертом не слежу.
Z>Предлагаю привести опровергающие примеры для предлагаемой фичи. Примеры, вроде "вот тут можно сделать как автосвойство, так и оставить обычное" не берем в рассчет, ок?
Не вопрос. Для какой фичи только? Их тут с пару десятков уже предложили. Если речь про "statement as expression" — чем плохи отдельные методы?
S>>Не, ну блииин, ребят, у себя вы так же к пользователям относитесь — "мне удобно, если у кого что поломается — их проблемы"? Z>Вы сейчас точно ко мне обращаетесь? У кого и что сломается?
Навкидку:
public void Foo(Action<int> a)
{
}
public void Foo(Func<int, string> b)
{
}
public void Bar()
{
Foo(delegate(int y)
{
Console.ReadLine(); // Какую перегрузку вызывать после добавления statement as expression?
});
Foo(delegate(int y)
{
return Console.ReadLine();
});
// Если не устраивает пример выше:
Foo(y => { Console.ReadLine(); }); // Тот же вопрос.
Foo(y => Console.ReadLine());
}
Если не хватает — можно ещё покопаться в property/collection initializers и в синтаксисе анонимных типов, там тоже могут возникнуть очень интересные неоднозначности.
Z>Я думаю тут неглупые люди, которые не раз создавали не инициализированные переменные перед блоками using и try, к примеру. Часто эти блоки являются expression именно для инициализации именно этой переменной. Часто переменная остается не инициализированной по ошибке программиста.
Останется не инициализированной — компилятор предупредит.
Проблема в том, что не менее часто блоки являются местом для добавления побочных эффектов — всё остальное спокойно реализуется через выражения.
Если разрешить использовать стейтменты в выражениях, мы убьём это различие и типовой код будет выглядеть как
int y;
var x = SomeLogicC() &&
try
{
SomeLogicA() & SomeLogicB();
}
catch(SomeException ex)
{
Log(ex);
y = 42;
false;
}
В общем, нечего тянуть ФП-привычки в грязный императивный мир
The first reason is that doing so violates the functional programming principles that all the other sequence operators are based upon. Clearly the sole purpose of a call to this method is to cause side effects.
Z>Ну это религия. Я раньше был ярым поклонником этой точки зрения, но потом, как-то отошел от догм. Просто сейчас пишу на разных языках, на C# и JS ощутимо недостает этой фичи, в отличии от Ruby&CoffeeScript.
Если гипотеза поддаётся проверке научными методами, то на религию это непохоже. Отсутствие побочных эффектов сильно упрощает код: меньше зависимостей, проще проверка корректности кода (вплоть до статической верификации через CodeContracts), проще растаскивать код на асинхронные вызовы и т.д. и т.п.
Да, в скриптовых языках возможность дописать чуть-чуть лапшекода ради экономии пары строк кода может быть очень удобной. Но в насквозь мейнстримном и приземлённом шарпе добавление сайд-эффектов в выражения приведёт только к одной реакции — "липперт разрешил"(с)
S>>Это типа удобная фича? Z>Покажите мне хоть одну фичу из уже введенных в язык, с которой я не смогу создать подобный говнокод?
Остальные фичи сдизайнены так, что накосячить сложнее, а к возможному говнокоду добавлен очевидный выигрыш. Тут, на мой взгляд, выгода очень неочевидна, вред:
if ({
await ALotOfCode1();
x == y;
})
{
ALotOfCode2();
}
— ужасен.
S>>Для экспериментов есть тонна других языков, зачем всё стаскивать в один?
Z>Это не эксперимент. Эта фича давно обкатана во множестве императивных языков.
Вот пусть она там и остаётся
Здравствуйте, Sinix, Вы писали: S>Здравствуйте, Ziaw, Вы писали: Z>>Липперта надо читать везде или только на stackowerflow? Я раньше читал его, но бросил, когда перестал делать ставку на один язык. Не могу сейчас уделять ему столько времени. S>Я подписан на блоги (старый, новый), на SO за Липпертом не слежу.
Так зачем предлагаете читать его блоги, если ответ на мой вопрос находится на SO? Z>>Предлагаю привести опровергающие примеры для предлагаемой фичи. Примеры, вроде "вот тут можно сделать как автосвойство, так и оставить обычное" не берем в рассчет, ок? S>Не вопрос. Для какой фичи только? Их тут с пару десятков уже предложили. Если речь про "statement as expression" — чем плохи отдельные методы?
Наша с вами беседа касается одной единственной фичи, я больше ничего не предлагал. Не надо так активно резать контекст. Я просил противоречий с: S>Почти всё, что добавлялось в шарп было: S>1. Полезным для определённых сценариев (даже именованные параметры вполне полезны, особенно для интеропа с вордом). S>2. Не дублировало имеющийся функционал, а дополняло его (автосвойства не отменили обычных свойств etc).
Навкидку:
S>
S> public void Foo(Action<int> a)
S> {
S> }
S> public void Foo(Func<int, string> b)
S> {
S> }
S> public void Bar()
S> {
S> Foo(delegate(int y)
S> {
S> Console.ReadLine(); // Какую перегрузку вызывать после добавления statement as expression?
S> });
S> Foo(delegate(int y)
S> {
S> return Console.ReadLine();
S> });
S> // Если не устраивает пример выше:
S> Foo(y => { Console.ReadLine(); }); // Тот же вопрос.
S> Foo(y => Console.ReadLine());
S> }
S>
S>Если не хватает — можно ещё покопаться в property/collection initializers и в синтаксисе анонимных типов, там тоже могут возникнуть очень интересные неоднозначности.
Это все решаемо. В данном случае можно предложить обязать использовать return как способ возврата значений из функции. Под это можно даже что-то религиозное подвести. S>Останется не инициализированной — компилятор предупредит.
Ну это же костыль, призванный компенсировать отсутствие данной фичи. Мне недостаточно средств языка, чтобы показать, что этот using мне нужен для вычисления одного конкретного значения. S>Проблема в том, что не менее часто блоки являются местом для добавления побочных эффектов — всё остальное спокойно реализуется через выражения.
Более того, методы являются местом для добавления побочных эффектов еще чаще. Что совершенно не мешает использовать их вызов в выражениях. S>Если разрешить использовать стейтменты в выражениях, мы убьём это различие и типовой код будет выглядеть как S>
Типовой говнокод. Он и сейчас выглядит не лучше. S>В общем, нечего тянуть ФП-привычки в грязный императивный мир
При чем тут, кстати, ФП? S>Да, в скриптовых языках возможность дописать чуть-чуть лапшекода ради экономии пары строк кода может быть очень удобной. Но в насквозь мейнстримном и приземлённом шарпе добавление сайд-эффектов в выражения приведёт только к одной реакции — "липперт разрешил"(с)
Что такое скриптовые языки? Чем лапшекод в них отличается от лапшекода в C#? Z>>Покажите мне хоть одну фичу из уже введенных в язык, с которой я не смогу создать подобный говнокод? S>Остальные фичи сдизайнены так, что накосячить сложнее, а к возможному говнокоду добавлен очевидный выигрыш. Тут, на мой взгляд, выгода очень неочевидна, вред:
Еще раз: покажите мне хоть одну фичу из уже введенных в язык, с которой я не смогу создать подобный говнокод. Z>>Это не эксперимент. Эта фича давно обкатана во множестве императивных языков. S>Вот пусть она там и остаётся
Слишком расползается ветка, давай про говнокод который можно создать отделим:
S>Если разрешить использовать стейтменты в выражениях, мы убьём это различие и типовой код будет выглядеть как
Сейчас ведь так не выглядит? Все возможности есть.
int y;
var x = SomeLogicC() &&
Statements.TryCatch(() =>
{
return SomeLogicA() & SomeLogicB();
}, (ex) =>
{
Log(ex);
y = 42;
return false;
})
Здравствуйте, Ziaw, Вы писали:
Z>Так зачем предлагаете читать его блоги, если ответ на мой вопрос находится на SO?
Потому что на SO рассмотрен конкретный, частный случай. Общие правила, по которым та или иная фича попадает в язык рассмотрены чуть ли не в каждой статье из блога. Классика — "because no one ever designed, specified, implemented, tested, documented and shipped that feature."
Блог Липперта ценен именно подробным рассмотрением последствий того или иного решения. В отличие от большинства ура-постов "что там думать — добавить и будет красиво", Липперт не ленится расписать все (зачастую весьма неочевидные) подводные камни и то, как они влияют на дизайн языка. На мой взгляд, такой сверхответственный подход к разработке — очень полезный навык. Лично мне чтение Липперта и не менее замечательной Framework Design Guidelines дало намного больше чем считающийся абсолютной классикой "Code Complete" МакКоннела.
Z>Наша с вами беседа касается одной единственной фичи, я больше ничего не предлагал. Не надо так активно резать контекст. Я просил противоречий с:
[пример противоречий скипнут] Z>Это все решаемо. В данном случае можно предложить обязать использовать return как способ возврата значений из функции. Под это можно даже что-то религиозное подвести.
Собственно в этом и заключается разница между теорией и практикой. На практике у нас появляются отдельные виды блоков — expression statement и return statement, довольно серьёзно меняется синтаксис, спецификация и, соответственно, реализация компилятора. Стоимость "одной маленькой фишки" становится сопоставимой с добавлением big thing уровня linq. При этом фишка останется чужеродной для всех, кто хотя бы год работал с шарпом, т.к. идёт в разрез с привычной идеологией "выражения — без побочных эффектов, стейтменты — для побочных эффектов".
Ещё один пример: Z>Мне недостаточно средств языка, чтобы показать, что этот using мне нужен для вычисления одного конкретного значения.
Сравните
int x;
using (var y = new SomeResource())
{
x = y.Z;
}
// vsvar x = using (var y = new SomeResource()) { y.Z };
Вот честно, какой вариант кода вам больше понравится поддерживать? И то же самое — если "вычисление одного конкретного значения" займёт несколько строк с несколькими if
И ещё: Z>>>Покажите мне хоть одну фичу из уже введенных в язык, с которой я не смогу создать подобный говнокод? S>>Остальные фичи сдизайнены так, что накосячить сложнее, а к возможному говнокоду добавлен очевидный выигрыш. Тут, на мой взгляд, выгода очень неочевидна, вред: Z>Еще раз: покажите мне хоть одну фичу из уже введенных в язык, с которой я не смогу создать подобный говнокод.
Пардон, но это уже сказка про белого бычка. Плиз, прочитайте всё что написано выше. Поймите, я не собираюсь доказывать, что фича XXX бесполезна. Моя позиция — её добавление создаст больше проблем, чем решает. Свои доводы я привёл, теперь ваша очередь
Для начала — покажите хоть один сценарий, который окупит все вышеперечисленные проблемы — как в реализации, так и в использовании. Только плиз, не надо отвечать "нет никаких проблем". Вот это как раз религия и неконструктивно
Здравствуйте, Sinix, Вы писали:
S>Вот честно, какой вариант кода вам больше понравится поддерживать? И то же самое — если "вычисление одного конкретного значения" займёт несколько строк с несколькими if
Вот такой. Постоянно так пишу.
def x = using (y = new SomeResource())
{
y.Z
}
S>Для начала — покажите хоть один сценарий, который окупит все вышеперечисленные проблемы — как в реализации, так и в использовании. Только плиз, не надо отвечать "нет никаких проблем". Вот это как раз религия и неконструктивно
Например, код выше.
Обе переменные неизменяемые. y виден только внутри using.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Вот такой. Постоянно так пишу.
def x = using (y = new SomeResource())
{
y.Z
}
Так это ж N, в нём этот код выглядит естественно и удобно — большинство переменных immutable и чтобы добавить странные побочные эффекты надо сильно постараться.
S>>Для начала — покажите хоть один сценарий, который окупит все вышеперечисленные проблемы WH>Например, код выше.
Если честно — спорно. Аналог в шарпе не сильно страшнее:
int x;
using (var y = new SomeResource())
{
x = y.Z;
}
Плюс, его не надо переписывать если нужно добавить побочные эффекты, если x надо инициалиизировать только в отдельных ветках разветвлённого if, или если надо заполнить несколько переменных.
Повторюсь, такие вещи надо с самого начала закладывать в язык, без кортежей и immutable by default подобное дополнение будет очень непрактичным.
Если добавить — мы получим уже не шарп, а урезанный диалект немерла, со своим стилем кодирования и дизайна API. Ну и зачем?
Здравствуйте, Sinix, Вы писали: S>Блог Липперта ценен именно подробным рассмотрением последствий того или иного решения. В отличие от большинства ура-постов "что там думать — добавить и будет красиво", Липперт не ленится расписать все (зачастую весьма неочевидные) подводные камни и то, как они влияют на дизайн языка. На мой взгляд, такой сверхответственный подход к разработке — очень полезный навык. Лично мне чтение Липперта и не менее замечательной Framework Design Guidelines дало намного больше чем считающийся абсолютной классикой "Code Complete" МакКоннела.
Где вы нашли ура пост? Я предложил фичу на обсуждение, аргументы против пока слабенькие. S>Собственно в этом и заключается разница между теорией и практикой. На практике у нас появляются отдельные виды блоков — expression statement и return statement, довольно серьёзно меняется синтаксис, спецификация и, соответственно, реализация компилятора. Стоимость "одной маленькой фишки" становится сопоставимой с добавлением big thing уровня linq. При этом фишка останется чужеродной для всех, кто хотя бы год работал с шарпом, т.к. идёт в разрез с привычной идеологией "выражения — без побочных эффектов, стейтменты — для побочных эффектов".
Появляется два вида блоков — тело функции и блок-выражение. Они и сейчас семантически различаются.
Ещё один пример:
Z>>Мне недостаточно средств языка, чтобы показать, что этот using мне нужен для вычисления одного конкретного значения. S>Сравните S>
S>int x;
S>using (var y = new SomeResource())
S>{
S> x = y.Z;
S>}
S>// vs
S>var x = using (var y = new SomeResource()) { y.Z };
S>
S>Вот честно, какой вариант кода вам больше понравится поддерживать? И то же самое — если "вычисление одного конкретного значения" займёт несколько строк с несколькими if
Ок, отвечу, а вы честно скажите: почему вы один вариант отформатировали, а второй слепили в кучу? Честно, мне второй симпатичнее, в общем случае, глядя внутрь первого блока я не понимаю, откуда взялась x, какого она типа, и для чего она понадобится дальше в блоке (или не понадобится). Меня всегда напрягают места, где значение ассайнится в какую-то непонятную переменную, надо искать что с ней будет дальше и где ее еще изменяют, а иногда еще и думать, что там было до этого и не потерялось ли оно по ошибке. Естественно я про реальный подобный код, а не трехбуквенный прототип. S>Пардон, но это уже сказка про белого бычка. Плиз, прочитайте всё что написано выше. Поймите, я не собираюсь доказывать, что фича XXX бесполезна. Моя позиция — её добавление создаст больше проблем, чем решает. Свои доводы я привёл, теперь ваша очередь
Естественно, потому, что посылка про то, что с этой фичей можно налабать много говнокода не выдерживает критики. А вы уже два раза избегаете ответа на прямой вопрос. Все описанные вами примеры говнокода можно воспроизвести без выражений. И все введенные с первой версии фичи позволяют наколобасить все более непонятный код, это неизбежная плата за возможности. Вы забыли аскетичность первой версии, если бы тогда нам показали сразу все фичи, которые появились сейчас, мы бы их все до одной отвергли как ненужное (за небольшим исключением, вроде generics). S>Для начала — покажите хоть один сценарий, который окупит все вышеперечисленные проблемы — как в реализации, так и в использовании. Только плиз, не надо отвечать "нет никаких проблем". Вот это как раз религия и неконструктивно
Я не говорю, что проблем нет, я прошу их показать. Одну проблему вы действительно показали (вывод типа функции), я предложил решение. А про побочное действие, это действительно религия, оно и сейчас в C# никак средствами языка не регулируется.
А окупит себя подход к дизайну кода, формирующий более внятные потоки данных в методе. После небольшого опыта написания кода на языке с иммутальными переменными, во всех языках стараюсь обходиться минимумом мутабельных. Код чище и понятнее выходит. Наверняка и вы это делаете, хотя бы на уровне полей класса, ведь других ограничений мутабельности шарп не дает. Так вот, без обсуждаемой фичи, количество локальных мутабельных переменных сократить до минимума не удается, хотя они нужны просто для перетаскивания значения из одной точки кода в другую и никаких изменений с ними по дороге не происходит.
Похоже на религию, я согласен, это сложно объяснить на пальцах, надо просто поприменять немного. Уфф. Чувствую себя человеком пытающемся объяснить пользу var тому, кто им плотно не пользовался.
Здравствуйте, Sinix, Вы писали:
S>Если добавить — мы получим уже не шарп, а урезанный диалект немерла, со своим стилем кодирования и дизайна API. Ну и зачем?
А ты погляди внимательно на все предложения в этих двух темах (тут и в дотнете). Почти все предложения и хотят фичей из немерла. Только многие боятся в этом признаться (даже сами себе), так как после этого придется отвечать на вопрос — "А почему просто не взять тот самый Немерл?".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Sinix, Вы писали:
S>>Если добавить — мы получим уже не шарп, а урезанный диалект немерла, со своим стилем кодирования и дизайна API. Ну и зачем?
VD>А ты погляди внимательно на все предложения в этих двух темах (тут и в дотнете). Почти все предложения и хотят фичей из немерла. Только многие боятся в этом признаться (даже сами себе), так как после этого придется отвечать на вопрос — "А почему просто не взять тот самый Немерл?".
У кого и что сломается?
