сразу подумалось о жабе

Дело вкуса

Дело вкуса

лаконичность

Нет, дело вкуса

Нет, дело вкуса

ок не стану переубеждать

Спор не имеет смысла

Лаконичность тоже дело вкуса.

так и не спорит никто

До релиза. Решарпер работал на предварительных сборках.

Почему мне никто не сказал?)

Почему мне никто не сказал?)

Дак ты не спрашивал!

У меня вчера какой-то глюк произошёл: ни одна клавиша в студии не работает. Отрубил решарпер - работает. Переставил решарпер, включил - неа. Переставил студию - неа. До 5 утра сидел. С перерывом на кваку)

Так я узнал, что есть новый решарпер))

ну для начала я бы вары использовал

а для конца? или это всё?

а для конца? или это всё?

*твоя аватара*

а для конца? или это всё?

строку интерполировал бы

и лябмду зачем городить непонятно

сложно и витиевато

Помните, я вчера писал, что бот вместо в 11 часов, написал сообщение в 4 часа? Сегодня он вообще не написал. :/

но видимо это все вкусовщина)

и лябмду зачем городить непонятно

А что вместо неё? Вот это самая суть!

Окей, есть какой-то полегче аналог hangfire?

Помните, я вчера писал, что бот вместо в 11 часов, написал сообщение в 4 часа? Сегодня он вообще не написал. :/

У него обед. Или выходной. суббота же

Аааа.

Ну тада сори)

А на самом деле я хз в чём прик.

божечки мой,ты не осилил за три дня хенгфайр

возьми кварц, он потопорней вроде

и лябмду зачем городить непонятно

окей, считай valuetype без лямбды менее витиевато, ну?

Console.WriteLine($"{typeof(A).GetField("x")}");

вкусовщина все это

понимаю

Console.WriteLine($"{typeof(A).GetField("x")}");

Это распечатает какой-нибудь FieldInfo, а не значение поля

лан ща приеду в дотнет фиддл запруфать попытаюсь

А дальше, если ты будешь каждый раз обращаться к FieldInfo::GetValue(), то уже перформанс просядет.

Ну то есть ты отчасти прав, и такое решение ранее предложили. Но вариант с Expression очень интересный.

А дальше, если ты будешь каждый раз обращаться к FieldInfo::GetValue(), то уже перформанс просядет.

+

А что я не так сделал то? foreach (Employer employer in employers.Values) { RecurringJob.AddOrUpdate($"{employer.Key", () => employers.Notify().Wait(), $"00 {employer.TimeToNotify} * * *"); }

А что я не так сделал то? foreach (Employer employer in employers.Values) { RecurringJob.AddOrUpdate($"{employer.Key", () => employers.Notify().Wait(), $"00 {employer.TimeToNotify} * * *"); }

$"{employer.Key" — тут ошибка.

А дальше, если ты будешь каждый раз обращаться к FieldInfo::GetValue(), то уже перформанс просядет.

не ну если это быстрее то спорить не буду

$"{employer.Key" — тут ошибка.

Я переписал криво, в проге норм стоит и запускается.

А что я не так сделал то? foreach (Employer employer in employers.Values) { RecurringJob.AddOrUpdate($"{employer.Key", () => employers.Notify().Wait(), $"00 {employer.TimeToNotify} * * *"); }

там есть CronUtils, это раз

не ну если это быстрее то спорить не буду

В одноразовом коде я бы написал так, как ты предлагаешь (потому что это проще), а вот в многоразовом имеет смысл сравнить варианты.

Я переписал криво, в проге норм стоит и запускается.

Ну ёпт, когда вы научитесь копипастить? :)

В одноразовом коде я бы написал так, как ты предлагаешь (потому что это проще), а вот в многоразовом имеет смысл сравнить варианты.

ьак я за одноразовый и вещал)

и интерполирование и вары к этому)

Ну ёпт, когда вы научитесь копипастить? :)

Руку надо набивать)(

что на шестом седьмом так в основном пишут

Вары ещё с четвёртого емнип

Но никто не заставляет ими пользоваться)

Вары ещё с четвёртого емнип

да

Кому-то хочется покороче, а кому-то появнее

Мне вот появнее

Да и решарпер сам всё за меня сделает)

Я всяких соглашений повидал. Кто-то вообще запрещает вары, например, кроме тех случаев, когда они обязательны

Мне только пробельчиком клацать

Мне вот появнее

так там в выражении типы понятны

А кто-то принудительно заставляет везде ими пользоваться.

так там в выражении типы понятны

А так сразу понятны, изначально

Ну и различные промежуточные варианты тоже встречаются во всяких компаниях.

А так сразу понятны, изначально

и двоится в глазах

Мне норм))

>вкусовщина

)

запрещают вары те, кто не любит dlr почем зря, принудительно заставляют кто любит менять выражения и ленится возиться с объявлениями

Как вары связаны с DLR?

изначально под dlr и ввели же

Нет.

ERROR: S client not available

Их ввели для анонимных типов.

Их ввели для анонимных типов.

я тож такое слышал

А для DLR всё равно отдельный кейворд dynamic, вары ему погоды не делают

Их ввели для анонимных типов.

Для анонимных типов и для LINQ вообще. Ну, чтоб не выписывать каждый раз вот эту простыню IEnumerable<IGrouping<TKey, TValue>> x = list.GroupBy(xxx);

все верно

https://github.com/alrz/roslyn/commit/4f0ef86fc9574c0fc097c679b5c284eabab40a75

мгм

Когда там уже val (или let) введут? А то как дикие джиесники, переиспользуем переменные без надобности..

https://github.com/alrz/roslyn/commit/4f0ef86fc9574c0fc097c679b5c284eabab40a75

О, в экспрешенах можно будет делать такие штуки?

Когда там уже val (или let) введут? А то как дикие джиесники, переиспользуем переменные без надобности..

Всё это костыли. Ъ посаны пишут в point-free и вообще не пользуются «переменными».

https://github.com/alrz/roslyn/commit/4f0ef86fc9574c0fc097c679b5c284eabab40a75

Как прелесть, только goto не хватает ?

Когда там уже val (или let) введут? А то как дикие джиесники, переиспользуем переменные без надобности..

const

? (и readonly для полей)

Как прелесть, только goto не хватает ?

чем goto плох?

О, в экспрешенах можно будет делать такие штуки?

Я был неправ, это не про Expression<T>, а просто дополнение вот к этому пропозалу: https://github.com/dotnet/csharplang/issues/176 Можно будет писать var x = true ?? return;

А чем ридонли для полей плох?

Адово, как по мне.

А чем ридонли для полей плох?

Раз уж у нас всё равно сегодня день микрооптимизаций, то напомню, что ридонли структуры в некоторых кейсах ведут себя хуже (медленнее, с большим количеством боксинга), чем обычные.

Медленне, это да

Но я не могу чото вспомнить, в каких же именно случаях.

С точки зрения написания кода это будет чуть быстрее чем свойство с геттером писать

И приватным полем

Вот что Скит пишет: https://codeblog.jonskeet.uk/2014/07/16/micro-optimization-the-surprising-inefficiency-of-readonly-fields/

Для чего вообще использовать приватный ридонли?

топовая наркомания в комментах: #if(DEBUG) private readonly int _x; #else private int _x; #endif

сразу сипипи запахло

Для чего вообще использовать приватный ридонли?

Ну, э, для полей, которые один раз в конструкторе инициализируются.

Я, например, всегда везде сую ридонли, где только можно.

Хм

Кстати, вроде, обещали, что в последних билдах JIT начал учитывать ридонли-флаг и делать полезные оптимизации.

Через рефлексию можно менять приватные поля, можно ли менять приватные ридонли?

Вроде бы да.