Comments 369
GetPerson().To(out var p).With ( /* deconstruction-like variations */ p.Name.To(out var name), /* right side assignment to the new variable */ p.Name.To(out nameLocal), /* right side assignment to the declared variable */ NameField = p.Name, /* left side assignment to the declared variable */ NameProperty = p.Name, /* left side assignment to the property */ /* a classical initialization-like variation */ p.Name = "AnyName" )
… и, простите, как конкретно это работает, учитывая, что у вас внутри With не анонимная функция? Что со скоупом переменных, временем выполнения и так далее?
PS
In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design.
Работает как обычная функция в которую передаются результаты выполнения выражений. Вообще в ней можно написать "левое" выражение типа "х=100/2". Выглядит все это забавно, но в реальной жизни я бы такое использовать не стал. Пользы нет, так ещё и лишние вызовы.
Работает как обычная функция в которую передаются результаты выполнения выражений
Спасибо, кэп. Вопрос как раз в том, как у "обычной функции" будет работать область видимости out var.
Так что в скомпилированном коде переменная будет точно проинииализирована, если не произойдёт исключений.
Будет явно объявлена локальная переменная в вызывающем методе.
То есть на самом деле нет никакого контекста с точки зрения метода, есть только визуальные скобки. И, например, я не могу ниже написать другой With, внутри которого я использую то же самое название переменной.
Да, одинаковые названия переменных будут конфликтовать, но есть возможность их повторного переиспользования.
С точки зрения метода 'With' есть контекст, который будет обратно возвращён в цепочку вызовов.
Вот только этот контекст никак не влияет на поведение With и на его аргументы.
(полезно сравнить и с With в VB.net, и со стандартной реализацией With как монады x.With(y => y.x))
Да, одинаковые названия переменных будут конфликтовать, но есть возможность их повторного переиспользования.
Во-первых, только если типы совпадают. Во-вторых, это худший вид побочного эффекта.
Лично для меня близка свобода в программировании, делай, как тебе нравится, а если что-то работает не так, то сам виноват. Меньше ограничений — больше возможностей.
Монады не позволяют совершать деконструкцию объекта и объявлять новые переменные для дальнейшего использования в вызывающем методе.
Польза не совсем очевидна, но здорово помогает писать bodied методы в одну цепочку.
Польза не совсем очевидна, но здорово помогает писать bodied методы в одну цепочку.
Я вас расстрою, но любой метод — bodied.
IModel GetModel() => new AnyModel();Это называется expression-bodied member.
new Person
{
Name = "AnyName"
}.DoSomethig();раскладывается компилятором в
var tmpContext = new Person();
tmpContext.Name = "AnyName"
tmpContext.DoSomething();В случае с 'With' мы декларируем контекст явно
new Person().To(out var p).With
(
p.Name = "AnyName"
).DoSomething();Единственное отличие состоит в дополнительном вызове метода 'With' для которого подготавливаются переменные в стеке. Декомпиляцию можно посмотреть тут.
В подавляющем большинстве практических случаев существенных накладок в производительность это не вносит, поскольку вся небольшая дополнительная работа ограничивается лишь стеком.
Для сравнения вVisualBasic есть оператор 'With', а доступ к временному контексту выполняется через '.', что-то пожее на следующий псевдо-код
new Person().With
{
.Name = "AnyName",
.ToString() to var stringView
}.DoSomethig();В любом случае, дело вкуса. Мне лично 'With' паттерн особенно нравится тем, что очень помогает писать bodied методы.
В случае с 'With' мы декларируем контекст явно
Вот задекларировали вы "контекст" (на самом деле — нет). Внутри него вызвали метод с out var. Какая будет область видимости у созданной переменной?
void Test()
{
GetPoint().To(out var p).With
(
p.X.To(out var x),
p.Y.To(out var y),
).DoSomething();
Console.WriteLine($"{x}, {y}");
}Вот я и говорю: нет никакого "контекста". Этот With не значит ничего.
Видимости структуризации, потому что, как мы только что выяснили, области видимости он тоже не создает. Ничего не значащие элементы — это мусор, от них надо избавляться.
Для меня видимость структуризации, читаемость и выразительность — очень близкие в данном случае понятия.
Но особенно меня цепляет глобальная симметричность и математическая красота подхода в плане обобщений. Это трудно объяснить и сразу прочувствовать, но мне самому теперь нравится, хотя поначалу были сомнения в его целесообразности.
"Выразительность" — это когда какое-то слово что-то выражает. А у вас есть слово With, которое ничего не выражает. Это отрицательная выразительность, если так можно выразиться.
А говорить о математической красоте, когда вы не просто вводите побочные эффекты, а ставите их своей целью, я бы не стал.
Приведу такую аналогию, у вас есть детская машинка, вы можете разобрать её на части и потом собрать. Поскольку все детали плотно подогнаны друг к другу, то вряд ли выйдет собрать что-то иное.
Теперь у нас есть конструктор или лего, из которых можно собрать множество вариаций автомобилей и не только, даже самых нелепых и абсурдных! Огромный простор для фантазии!
В программировании для меня намного более близок второй подход. Пускай лучше инструменты позволяют делать даже бредовые вещи, как их примениять или не применять, это уже мне самому потом решать. :)
Вообще-то в нашем случае 'with' выражает пусть и видимую, но вполне осязаемую структуру кода.
Да нет же. Ничего осязаемого, никакой границы у этого элемента кода нет — я могу ее пересекать в любую сторону, все, что я в ней делаю, отражается снаружи и наоборот.
Пускай лучше инструменты позволяют делать даже бредовые вещи, как их примениять или не применять, это уже мне самому потом решать.
Этот подход плохо применим в командной работе.
Этот подход плохо применим в командной работе.
Отчасти поэтому мне больше нравится писать код самостоятельно. Но как бы там ни было, я совсем не принуждаю кого-то следовать рассмотренным концепциям, всего лишь делюсь личным опытом и наработками.
Если вам любпытно, то вы и сами можете немного полазить по репозиториям и субъективно оценить качество кода, написанного мной. ))
Граница есть, но лишь условная, поэтому вы можете её свободно пересекать в любую сторону — в этом своя прелесть!
Нет в этом прелести, в том-то и дело. Это банальный обман ожиданий.
Если вам любпытно, то вы и сами можете немного полазить по репозиториям и субъективно оценить качество кода, написанного мной
Спасибо, мне достаточно примеров кода, которые вы приводите в дискуссиях.
Я считаю, что то, что человек сам считает возможным показывать публично, достаточно много о нем говорит.
C# и .NET это в основном язык для кровавого энтерпрайза и для девелоперов с мат аппаратом ниже среднего.
Выше среднего идут в игроделанье или сток трейдинг какой-нить и фигачут все на С/С++ без границ.
Но всё же если взять среднюю.нет кодбазу, то над ней больше часов проводят девелоперы, которые её не писали с нуля и которые не знают всю окружающую инфраструктуру. Девелоперы в среднем хорошо знают C#, встроенные апи .NET, самые популярные нугет пакеты и мб специализированные фреймворки.
Поддерживать, менять и профилировать такой код сложнее чем прямолинейный нативный C#, если ты работраешь с этим кодом раз в год.
И согласен с lair про скоп out параметров, он сделан довольно коряво из-за наследия C#, также как и is var x и case int x. Поэтому использовать хорошо и без неожиданных сюрпризов это можно в коротких узкоспециализированных методах в которых уже становится не очень важно насколько красиво они написаны.
Может быть, кто-то захочит покрутить их в свои личных проектах, а кто-то внедрит и в коммерческий. В публикации я никого не призываю делать их мейнстримом, только лишь делюсь личным опытом и наработками.
В любом случае, иногда полезно взглянуть даже на хорошо знакомые вещи с другой стороны. Своего рода разминка для ума. :)
А что по поводу производительности — открыл sharplab по вашей ссылки, перешел в IL — там же какой-то локальный ад?
… ну да, например вот все вызовы статических функций-пустышек не инлайнятся.
Думаю, что современные языки отлично оптимизированы для работы со стеком вызовов и поощеряют разделение кода на маленькие методы.
Моё понимание интуитивно, поэтому могу ошибаться, поправьте, если что не так. :)
Думаю, что современные языки отлично оптимизированы для работы со стеком вызовов и поощеряют разделение кода на маленькие методы.
… в основном они пытаются эти "маленькие методы" инлайнить. Наверное, не просто так. И наверное не просто так на куче таких маленьких методов стоит хинт "инлайнить максимально агрессивно".
var w = new Stopwatch();
w.Start();
for (int i = 0; i < 100000000; i++)
{
w.With(w, i);
}
w.Stop();
System.Console.WriteLine(w.ElapsedMilliseconds);На моём не самом передовом компьютере 100 000 000 вызовов заняли около секунды на релизном билде. То есть вызов 'With' занимает 1/100 000 000 (одну стомиллионную секунды)!
Не знаю, как вам, но для моих задач этого хватит с лихвой.
Конечно, в редчайших случаях, где важна сверхпроизводительность, инлайнинг, наверняка, помогает, но это уже другая область в разработке.
Так что не стоит сгущать краски над 'With', вызов этот занимает порядка одной стомиллионной секунды на среднем компьютере. Уверен, что даже для мобильных устройств эта цифра будет вполне адекватная.
Вы пробовали когда-нибудь замерить, скольколько же стоит вызов пустого метода?
Вы когда-нибудь читали, как правильно делать микробенчмарки?
Буду рад распрощаться со своими заблуждениями насчёт вызова пустых методов.
Да пожалуйста:
BenchmarkDotNet=v0.10.14, OS=Windows 10.0.16299.371 (1709/FallCreatorsUpdate/Redstone3)
[Host]: .NET Framework 4.7.1 (CLR 4.0.30319.42000), 32bit LegacyJIT-v4.7.2633.0
DefaultJob: .NET Framework 4.7.1 (CLR 4.0.30319.42000), 32bit LegacyJIT-v4.7.2633.0
Method | Mean | Error | StdDev |
-------- |-----------|-----------|-----------|
With | 27.082 ns | 0.3048 ns | 0.2545 ns |
Without | 6.095 ns | 0.2036 ns | 0.1904 ns |Разница в четыре с половиной раза.
public class Person
{
public string Name { get; set; }
public int Age { get; set; }
}
public class WithAndWithout
{
private readonly string _name = Guid.NewGuid().ToString();
private readonly int _age = 42;
[Benchmark]
public object With()
{
return new Person()
.To(out var p)
.With(
p.Name = _name,
p.Age = _age
);
}
[Benchmark]
public object Without()
{
return new Person
{
Name = _name,
Age = _age
};
}
}
public static class Q
{
public static T To<T>(this T o, out T x) => x = o;
public static T With<T>(this T o, params object[] pattern) => o;
}
public class Program
{
static void Main(string[] args)
{
var summary = BenchmarkRunner.Run<WithAndWithout>();
}
}Поэтому для себя не вижу существенных причин отказываться от 'With'.
Но когда речь идёт о стомиллионных долях секунды, то разница в пять и даже сто раз просто не ощутима на практике
Это пока вы не создаете объекты сотнями тысяч и миллионов. Пять секунд против секунды — и упс.
Поэтому для себя не вижу существенных причин отказываться от 'With'.
Ну то есть вас перформанс не волнует, на самом деле. Ок.
Обычно в таких сценариях, где много данных и важна высокая скороть их обработки, уже пишут код на более низкоуровневых языках.
Сто накладных, тысяча наименований на накладную — вот вам и сто тысяч объектов. Теперь представили, что у вас ORM и внешний DTO — помножили на три. А это так, ленивый день на обувном складе.
Там действительно 5 секунд лишних за день не выделить?
То, о чём вы говорите, это сценарий для высоконагруженного сервера, кэширующего данные в памяти, или же очень специфического клиента. А для исключений нужны и исключительные решения.
Поэтому не вижу смысла отказываться от паттерна общего назначения, из-за каких-то маловероятных падений производительноти. Если вдруг начнёт что-то ощутимо замедляться из-за вызовов 'With', то не вижу проблемы их убрать, благо, код не потребует огромной реструктуризации.
Ох, не знаю, какой у вас проект, но обычно никто не держит в памяти по сто тысяч объектов за редкими исключениями.
А я и не говорил, что их держат в памяти, их прочитали-трансформировали-записали, но это же все равно столько же созданий объектов.
Поэтому не вижу смысла отказываться от паттерна общего назначения, из-за каких-то маловероятных падений производительноти.
Вообще-то, ничего маловероятного: воспроизводится стабильно, с сопоставимыми результатами.
Если вдруг начнёт что-то ощутимо замедляться из-за вызовов 'With', то не вижу проблемы их убрать, благо, код не потребует огромной реструктуризации
… а зачем он тогда нужен?
Я, например, точно знаю, что в моих текущих проектах такого не придвидится, поэтому для себя никаких причин отказываться от паттерна не вижу.
По крайней мере, можно его использовать в задачах, где свехвысокая производительность не критична.
Обычно в таких сценариях, где много данных и важна высокая скороть их обработки, уже пишут код на более низкоуровневых языках.
Не в первый раз встречаю это странное утверждение. Если на низкоуровневом языке использовать подобного рода конструкции, то тоже ничего хорошего не выйдет.
-Нисколько.
-Отлично! Накапайте стаканчик!"
Весь наш код складывается из «стомилионных долей секунды». Каждый вызов, каждая строчка, каждое выражение. Если вы пишете, например, десктопный UI, то пользователь, скорее всего, не заметит просадки ни в пять ни в сто раз. Но в бэкенде, это окажется критичным. А подход лучше использовать один ко всему коду.
"-Сколько у Вас стоит капля водки?
-Нисколько.
-Отлично! Накапайте цистерну!
-Без проблем! Начинайте капать..."
Да и если здраво подойти к вопросу, то
"-Сколько у Вас стоит капля водки?
-Нисколько.
-Отлично! Накапайте стакан!
-Стакан стоит столько-то центов..."
:)
У вас в хелперах:
public static T With<T>(this T o, params object[] pattern) => o;
Что приводит к боксингу int'а в
.With(
p.Name = _name,
p.Age = _age
);
В то время как у Makeman эти хелперы объявлены так, что боксинга не будет:
public static T With<T>(this T o) => o;
public static T With<T, A>(this T o, A a) => o;
public static T With<T, A, B>(this T o, A a, B b) => o;
public static T With<T, A, B, C>(this T o, A a, B b, C c) => o;
Чтобы не быть голословным, на моей машине бенчмарк вашего кода
BenchmarkDotNet=v0.10.14, OS=Windows 7 SP1 (6.1.7601.0)
Intel Xeon CPU X5670 2.93GHz, 1 CPU, 12 logical and 6 physical cores
Frequency=2864628 Hz, Resolution=349.0855 ns, Timer=TSC
[Host] : .NET Framework 4.7.1 (CLR 4.0.30319.42000), 32bit LegacyJIT-v4.7.2563.0
DefaultJob : .NET Framework 4.7.1 (CLR 4.0.30319.42000), 32bit LegacyJIT-v4.7.2563.0
Method | Mean | Error | StdDev |
-------- |----------:|----------:|----------:|
With | 21.618 ns | 0.5293 ns | 0.4692 ns |
Without | 5.212 ns | 0.2985 ns | 0.2931 ns |
Разница действительно больше чем в четыре раза.
Бенчмарка кода c поправленными хелперами:
BenchmarkDotNet=v0.10.14, OS=Windows 7 SP1 (6.1.7601.0)
Intel Xeon CPU X5670 2.93GHz, 1 CPU, 12 logical and 6 physical cores
Frequency=2864628 Hz, Resolution=349.0855 ns, Timer=TSC
[Host] : .NET Framework 4.7.1 (CLR 4.0.30319.42000), 32bit LegacyJIT-v4.7.2563.0
DefaultJob : .NET Framework 4.7.1 (CLR 4.0.30319.42000), 32bit LegacyJIT-v4.7.2563.0
Method | Mean | Error | StdDev |
-------- |---------:|----------:|----------:|
With | 9.931 ns | 0.2884 ns | 0.4042 ns |
Without | 5.341 ns | 0.1552 ns | 0.1376 ns |
Разница уже не в 4, а примерно в два раза. Имхо, все равно достаточно большая.
P.S. Я не уверен, но, возможно, если отметить методы аттрибутом
[MethodImpl(MethodImplOptions.AggressiveInlining)], то результаты могут ещё немного улучшиться…Осталось это смасштабировать на типичную такую инициализацию с десятью-пятнадцатью параметрами.
GetModel().To(out var m)
.With(m.A0 = a0, ... , m.AN = aN)
.With(m.B0 = b0, ... , m.BM = bM).Save();Ну во-первых, это становится менее читаемо (интент перестает быть очевиден). А во-вторых, надо же считать перформанс после такого.
new Person().To(out var p).With(
PropA = aA,
...
PropN = aN).With(
PropM = aM,
...
PropZ = aZ).DoSomething();Конечно же, при необходимости можно просто создать перегрузки метода With и для большего числа параметров.
Производительность можете сами проверить, как показывают мои опыты, подобные конструкции очень близки по скорости выполнения к классическим инициализационным блокам.
При аккуратном форматировании читаемость не слишком страдает
Ну то есть мы читаем, внезапно видим между двумя присвоениями With и просто игнорируем его, да?
Вот понимаете, когда есть синтаксический элемент, который нужно пропускать — это ухудшение читаемости.
Вот только беда в том, что никто не знает, сколько перегрузок надо. А метод With, понятное дело, должен лежать не в моем коде, поэтому каждое добавление — это редеплой.
(У вас, конечно, есть репрезентативная статистика про "16 параметров покроют"?)
Да, давайте сделаем 16 оверлоадов, а когда их не хватит — все равно будем использовать мусорный синтаксис. Никакого оверхеда, да. По-моему, намного проще использовать обычные инициализационные блоки.
… а теперь давайте подумаем, сколько таких сценариев (в процентах), и задумаемся — а стоит ли этот оверхед того?
Во-первых, инициализация.
Во-вторых, деконструкция, которая во многих случаях более удобна, чем стандартный аналог с методами Deconstruct.
В-третьих, цепочная замена конструкций if-else при проверках на null.
И наконец, вы же не противитесь внедрению 'is {… }'? Хотя Check паттерн (родственный With) гораздо более гибкий и интуитивный.
Даже у меня в простеньком текстовом редакторе нашлось несколько мест, где With весьма органично вписался. Поэтому было бы желание — применение найдётся.
Во-первых, инициализация.
Для инициализации есть инициализационные блоки (а еще лучше — конструкторы и разного рода билдеры, потому что immutabity упрощает рассуждение).
Во-вторых, деконструкция, которая во многих случаях более удобна, чем стандартный аналог с методами Deconstruct.
Продемонстрируйте.
В-третьих, цепочная замена конструкций if-else при проверках на null.
… и как вы для этого используете With?
И наконец, вы же не противитесь внедрению 'is {… }'? Хотя Check паттерн (родственный With) гораздо более гибкий и интуитивный.
А кто вам сказал, что ваш Check более интуитивный? Особенно опять-таки в части порядка и условности выполнения.
Я вам больше того скажу, меня is волнует сильно во вторую очередь. Меня волнует "большой" паттерн-матчинг в виде switch (особенно когда наконец сделают switch expressions), а is — это его побочный эффект, сделанный для симметрии.
Поэтому было бы желание — применение найдётся.
Это плохой подход. "У меня есть молоток, поэтому я поищу что-нибудь, чтобы забить, пусть даже это будет шуруп". Ровно наоборот, применение должно расти из необходимости.
Продемонстрируйте.
GetPerson().To(out var p).With(
p.Name.To(out var name),
p.Age.To(out var age)
)./* use of 'name' and 'age' */У класса Person может быть хоть сотня свойств и полей, но мне не нужно добавлять десятки перегрузок метода Deconstruct, я просто вывел в переменные те свойства, что мне были нужны, причём, в произвольном порядке.
… и как вы для этого используете With?
Вы ведь уже видели.
(o, e) =>
App.Current.MainWindow.To(out var w)?.With(w.Title = "x");А паттерн-матчинг — фича интересная, но некоторые детали реализации в C# оставляют желать лучшего. Мне вообще думается, что 'is {… }', может, и не выйдет в релиз… Поживём — увидим.
GetPerson().To(out var p).With( p.Name.To(out var name), p.Age.To(out var age) )
Серьезно?
var p = GetPerson();
var name = p.Name;
var age = p.Age;Меньше кода, меньше оверхеда, лучше читается, никакого WTF. Деконструкция здесь просто не нужна.
(o, e) => App.Current.MainWindow.To(out var w)?.With(w.Title = "x");
Аналогично:
(o, e) =>
{
if (App.Current.MainWindow is Window w)
w.Title = "x";
};Явно описанные побочные эффекты — наше все.
А паттерн-матчинг — фича интересная, но некоторые детали реализации в C# оставляют желать лучшего.
Это смотря с чем сравнивать. Ну да, F# мне нравится больше. Но F# имеет свои занятные особенности (и с вашей манерой писать совместим, кстати, исключительно плохо).
Меньше кода, меньше оверхеда, лучше читается, никакого WTF. Деконструкция здесь просто не нужна.Вы, похоже, не уловили сути. Деконструкция и инициализация с With позволяют выводить, объявлять и обновлять значения где угодно в цепочных вызовах без кардинальной смены структуры кода.
string _newName = "abc";
bool UpdateData(Person p) => p.With(
p.Name.To(out var oldName),
p.Name = _newName)
)
.Use(() => Debug.WriteLine($"Name changed from {oldName} to {_newName}"))
.TrySave();Например, тут присутствует временный дебажный вывод, который может быть легко удалён без смены структуры кода.
string _newName = "abc";
bool UpdateData(Person p) => p.With(
p.Name = _newName)
)
.TrySave();(o, e) =>
{
if (App.Current.MainWindow is Window w)
w.Title = «x»;
};
With для того мне и нужен, чтобы избежать скобок и конструкций вида if-else, вы же предлагаете мне вернуться к старому варианту, который всегда был мне не по душе. И да, я хочу использовать вывод типов без всяких хаков, а не указывать их явно как Window w.
Это смотря с чем сравнивать. Ну да, F# мне нравится больше. Но F# имеет свои занятные особенности (и с вашей манерой писать совместим, кстати, исключительно плохо).
Активно не использую F#, но реализация паттерн-матчинга там чище, чем в C#. Хотя и он меня вполне устраивает, особенно с кастомными To-With-Is-Check.
Вы, похоже, не уловили сути. Деконструкция и инициализация с With позволяют выводить, объявлять и обновлять значения где угодно в цепочных вызовах
Я боюсь, это вы не уловили сути. Обявление (внешних по скоупу) переменных и обновление их значений — это как раз то, чего я предпочел бы избежать в цепочечных вызовах, равно как и любых других побочных эффектов.
Например, тут присутствует временный дебажный вывод, который может быть легко удалён без смены структуры кода.
Я не вижу проблемы поменять структуру кода здесь — это секунд 15 в нормальной IDE.
With для того мне и нужен, чтобы избежать скобок и конструкций вида if-else, вы же предлагаете мне вернуться к старому варианту, который всегда был мне не по душе.
Если вам не по душе императивное программирование, зачем вы издеваетесь над императивным языком?
var ((x, y, z), t, n) = (1, 5, "xyz");и
if (GetPerson() is Person p && p.Check
(
...
p.City.To(out var city).Put(true), /* always true */
p.Age.To(out var age) > 23
).All(true)) ...Очень сложно увязать с
позволяют сделать код более чистым и выразительным
public static T With<T>(this T obj, Action<T> initializer) {
initializer(obj);
return obj;
}То есть:
var manager = GetPerson().With(o => {
o.FirstName = "Иван";
o.LastName = "Пупкин";
});
Наглядность здесь не менее спорная, но по крайней мере не будет захламляться внешняя область видимости.
Так и до NLombok недалеко...
— нельзя без замыканий выводить значения в новые переменные (производить деконструкцию объекта)
var manager = GetPerson().To(out var p).With(
p.FirstName.To(out var oldFirstName),
p.FirstName = "Иван",
p.LastName = "Пупкин",
p.ToString().To(out var personStringView),
});— нет возможности удобно модифицировать структуры
struct Person { ... }
var manager = GetPerson().With(o => {
o.FirstName = "Иван";
o.LastName = "Пупкин";
});
Console.WriteLine(manager.FirstName); // получим исходное значение вместо "Иван" — больше скобок и меньше похоже на инициализационные блоки
Хотя, конечно, никто не отменяет и этот подход, кому что ближе. :)
p.FirstName.To(out var oldFirstName),
p.FirstName = "Иван",
А как вы решаете где применять левое присваивание, а где правое? Не от наличия With, надеюсь?
Правое присваивание очень уместно в таких случаях:
— expression-bodied методах
— при деконструкции объектов
— в цепочных вызовах
Левое присваивание на данный момент больше подходит для:
— арифметических выражений
— при присваивании свойств (к ним нельзя применить правое присваивание в текущей реализации, хотя если бы существовал на уровне языка оператор 'to', то можно было бы применять и для них)
В остальных случаях ориентируюсь по контексту, где что лучше смотреться будет.
А зачем? Вас кто-то заставляет expression-bodied использовать?
Или вы на столько не любите фигурные скобочки, что готовы внедрить лишний оператор?
— в цепочных вызовах
тогда надо сразу делать .Then(expr) вместо; и .Return(expr) вместо return — можно что угодно в expression-bodied и цепочку запихнуть.
• провоцирует оформлять код мелкими методами с раздельной отвественностью
• меньше скобок и лишних слов вроде return
• эстетически красиво и лаконично
• развивает чувство прекрасного
• учит писать чистый и общённый код
И лично для меня последние пункты самые важные. :)
Если бы не эта математическая красота, то давно бы уже забросил программирование!
Или писать адовые однострочники в стиле: «Смотри, как я могу!» ?) Всё в меру хорошо, но к красивому коду это склоняет настолько же, насколько и к говнокоду.
- эстетически красиво и лаконично
- развивает чувство прекрасного
Как уже говорил ранее, мне близок дух изобретательства и свободы в программировании. Но каждому человеку своё — кому-то больше по душе традиционные подходы.
Но я думаю, что есть и такие люди, которым интересен новаторский взгляд в программировании, а эта статья поможет им взглянуть на знакомые вещи с другого ракурса…
Вы про «expression-bodied» или про «expression-bodied с правым присваиванием и другим хламом»? С первым я может и согласился бы…
Но я плохо понимаю, например, как у вас «провоцирует оформлять код мелкими методами с раздельной отвественностью» привело к совмещению деконструкции, update, и генерации view в одном выражении.
Насчёт совмещения — это демонстрационный пример, задача которого показать различные сценарии использования. Конечно, я бы мог разбить его на более мелкие части, но в собранном виде мне нравится больше.
По ссылке можно увидеть пример стиля, в котором я предпочитаю писать код.
По ссылке можно увидеть пример стиля, в котором я предпочитаю писать код.
Дадада.
Documents.ForEach(d => d.Expose()).ForEach(async d => await d.Load());А теперь давайте попробуем понять, что это такое, как оно вообще работает, и что же у него с реальным временем выполнения.
Одна строчка, одна.
Если вы хотите подковырнуть меня тем, что я дважды прохожусь по коллекции, то здесь это никаких проблем не вызывает.
Можете даже скомпилировать проект и убедиться, что всё работает вполне себе живо. :)
в первом цикле инициализируем вью-модели документов
Ну то естьForEach(d => d.Expose())меняет состояние объектов в коллекции.
а во втором асинхронно загружаем в каждую информацию из файлов.
Асинхронно с ожиданием или без? Параллельно или последовательно?
Без ожидания. Серьезно.
То есть у вас, на самом деле, на момент окончания метода CoreViewModel.Expose нет гарантий ни того, что документы на самом деле инициализированы, ни того, что эта инициализация прошла без ошибок.
Круто, да.
На момет окончания метода 'CoreViewModel.Expose' важно выполнить лишь Expose у коллекции документов, а загрузкой данных из файла заведует сам документ.
Ошибки загрузки из файла обрабатываются в самих дочерних вью-моделях.
Это тоже очень очевидно в вашем коде. Особенно учитывая, что ADocument — абстрактный класс, и там может быть что угодно в коде.
а загрузкой данных из файла заведует сам документ.
Тогда почему этот код вызывается из обсуждаемого метода, а не из самого документа?
public abstract Task<bool> Load();
public abstract Task<bool> Save();
public abstract Task<bool> SaveAs();
public abstract Task<bool> Close();Подразумевается, что в случае успешного выполнения возвращается true, иначе false.
Когда основная вью-модель вызывает у дочерней один из этих методов, то это выглядит, словно руководитель выдаёт подчинённому команду что-то сделать, ставит задачу.
Это не забота руководителя, каким образом подчинённый будет выполнять задание и обрабатывать возникающие трудности (исключения), важен лишь конечный результат и то, что руководитель выполнил свою работу по постановке задачи. Классическое разделение ответственности.
Подразумевается, что в случае успешного выполнения возвращается true, иначе false.
Исключения? Нет, не слышали.
Ладно, фиг с ними, с исключениями, но вы же и результат выполнения никак не проверяете.
Когда основная вью-модель вызывает у дочерней один из этих методов, то это выглядит, словно руководитель выдаёт подчинённому команду что-то сделать, ставит задачу.
Ну то есть все-таки за то, чтобы инициировать загрузку отвечает родительская модель. Но при этом она никак не проверяет, завершилась ли эта задача — успешно, неуспешно, хоть как-то. Знаете, у вас очень странное понятие о супервизии.
Классическое разделение ответственности.
В "классическом разделении ответственности", если сказано "важно выполнить лишь Expose у коллекции документов, а загрузкой данных из файла заведует сам документ", загрузка вызывается "самим документом". А если внешний код вызывает и Expose, и Load, значит, ему важны оба.
Я не против разделения ответственностей, я против неконсистентности и игнорирования ошибок.
В первую очередь я отталкиваюсь от логики самой программы, сейчас она функционирует отлично.
Главной вью-модели вообще ни к чему знать об исключениях, возникающих в работе докуметов, там произойти может, что угодно: нет доступа к файлу, формат не тот… Пускай документы сами разбираются, что с этим делать. Задача руководителя лишь создавать их и закрывать, когда нужно, попутно уведомляя о загрузке, закрытии и сохранении.
Ошибки (исключения) не игнорируются, вы можете в этом убедиться сами, запустив приложение.
Documents.ForEach(d => d.Expose()).ForEach(async d => await d.Load());Хорошо видно, что результат выполнения игнорируется. При этом, кстати, совершенно не понятно, зачем вам там async-await, хотя без него можно (дважды) обойтись.
Если результат выполнения не игнорируется, это еще одна прекрасная иллюстрация к вашему утверждению о читаемости кода.
В первую очередь я отталкиваюсь от логики самой программы, сейчас она функционирует отлично.
Ну вот видите: от логики, а не от читаемости. Об этом и речь.
А потом сравните количество и читаемость получившегося кода. Получится лучше — поделитесь с сообществом своими наработками и видением. )
"Сперва добейся"? Спасибо, но нет.
Конечно, я обычный человек, который может ошибаться, но над архитектурой редактора размышлял очень много времени. Это не единственный возможный вариант, но он мне очень даже нравится.
Понимаете ли, мне искренне все равно, какая у вас архитектура. Меня интересует конкретная процитированная мной строчка, в которой я наблюдаю как минимум две (на самом деле — больше) проблемы. С архитектурой она никак не связана, это проблема именно читаемости конкретной строчки.
1. Подготовили докуметы к работе
2. Асинхронно вызвали параллельную загрузку данных в каждый
Всё. Документы уже готовы к работе и сами разберутся, что делать при возникновении ошибок.
Во-первых, из строчки не очевидно, что загрузка параллельна.
Во-вторых, из строчки не очевидно, что будет с результатом загрузки.
И в-третьих, зачем там async...await?
Для меня эта строчка выглядит вполне ясно и естественно.
Потому что вы знаете, что внутри каждого из методов, который в ней вызывается.
public static IList<T> ForEach<T, TR>(
this IList<T> collection,
Func<T, TR> action)
{
foreach (var item in collection)
action(item);
return collection;
}После этого многие вопросы пропадают, и вас уже не смущает этот же вызов в другом месте программы.
Нет, это не нормально. Я не хочу лазить за деталями имплементации, я хочу, чтобы происходящее было понятно из написанного кода. Это и называется "читаемостью".
Заметим, кстати, что даже из приведенного вами кода не очевидно, что загрузка параллельна (и, собственно, она совершенно не обязательно будет параллельной), и все так же не понятно, зачем нужен async...await.
Ваши претензии насчёт «читаемости» кода лучше адресовать к архитекторам C#, которые ввели именно такую реализацию async...await с немалым количеством подводных камней.
Что касается написанного именно мной кода, то он весьма тривиален — это всего лишь цепочные вариации метода ForEach очень схожие с одноименным методом у класса List. То есть запросто без всяких дополнительных расширений сейчас можно писать такой код
new List<ADocument>() {...}
.ForEach(async d => await d.DoSomething());Насколько понимаю, вы хотите сказать, что интуитивное добавление async...await ломает его читабельность?
Да, я ошибся с тем, что он должен выполняться параллельно, но при искуственном добавлении задержки в метод Load ничего в моей программе не сломалось и не заблокировалось, просто текст из файла загрузился чуть позже, из чего делаю вывод, что интуиция меня не подвела и работает код, по крайней мере, асинхронно, как и хотелось.
Ваши претензии насчёт «читаемости» кода лучше адресовать к архитекторам C#, которые ввели именно такую реализацию async...await с немалым количеством подводных камней.
Эээ, а при чем тут это, учитывая, что в вашем коде async...await не нужен?
Насколько понимаю, вы хотите сказать, что интуитивное добавление async...await ломает его читабельность?
Ну да, потому что нет ничего интуитивного в асинхронии в цикле, а особенно — в итераторе. И тем более нет ничего интуитивного в запихивании асинхронного метода внутрь метода, выглядящего синхронным (если, конечно, он не называется Run... или Queue...).
Тасками я пользуюсь по большей части интуитивно и стараюсь избегать дебрей с контекстами синхронизации.
И на что вы мне предлагаете его заменить?
Вы не поверите, просто убрать. Вы серьезно мне хотите сказать, что вы не знаете, как поведет себя система, если вместо async () => await SomeAsync() написать () => SomeAsync()?
Тасками я пользуюсь по большей части интуитивно и стараюсь избегать дебрей с контекстами синхронизации.
Не надо так делать, надо документацию читать. Или вот того же Клири очень полезно.
async () => await SomeAsync() запускает таск, а вот () => SomeAsync() просто его возвращает, не запуская.Task task
...
() => task = SomeAsync()И как вообще я могу убрать await в таком случае?
...ForEach(async d => await d.Close() && Documents.Remove(d))Насколько я понимаю, вызов async () => await SomeAsync() запускает таск, а вот () => SomeAsync() просто его возвращает, не запуская.
Вы понимаете неправильно. В обоих случаях "запуск" таска зависит исключительно от поведения SomeAsync (хотя на самом деле, нет такой вещи как "запуск" таска, и это вообще некорректная постановка вопроса).
И как вообще я могу убрать await в таком случае?
В таком — не можете, но в приведенном мной примере написано не так (другое дело, что в новом примере — новые проблемы, но в эту кроличью нору можно бесконечно спускаться).
async void Load() => await ...
...ForEach(d => d.Load());В моём случае с Load я не могу убрать await, поскольку метод возвращает таск, который мне нужно запустить.
Что значит "запустить таск"? Нет такой вещи в TPL.
Ваш Load в его живой имплементации рано или поздно долетает до банального Task.Factory.StartNew, который, собственно, и кладет задачу в диспетчер, безотносительно того, делали вы await или нет (а вы его сделали сразу, кстати, и тоже совершенно незачем).
(отдельно, конечно, прекрасно то, что вы кладете IO-bound-задачу в отдельную задачу вместо того, чтобы взять IOCP-bound ReadToEndAsync)
Интуиция такая интуиция, да.
Насколько понимаю, если вместо StartNew буду использовать ReadToEndAsync, то тогда await убрать не смогу, верно? Или интуиция опять подводит?
Опять подводит.
var tasks = docs.Select(d => d.AnyTask()).ToArray();
docs.ForEach(async d => await d.AnyTask());В первом случае хочу просто собрать таски и выполнить их потом. Во втором хочу начать выполнять немедленно. Как мне различить эти ситуации? В первом случае таски начнут выполняться сейчас же?
Что значит "запустить таск"? Нет такой вещи в TPL.
Ну вообще есть, но ей никто не пользуется
По умолчанию таски в TPL горячие.
фиксанул ссылку
Спасибо за напоминание, я уже и забыл, что так бывает. Был не прав.
Другое дело, что это очень и очень редкий случай, и — как уже писали ниже — конвенция предполагает, что Task, возвращенный из метода, соответствует запущенному коду, а не коду, который ожидает, что его запустят (еще и потому, кстати, что Task.Start не идемпотентен).
static async Task LoadAsync() => await new Task(() => System.Console.WriteLine("Load Async"));
static Task Load() => new Task(() => System.Console.WriteLine("Load"));
static async void Test()
{
System.Console.WriteLine("Start");
await LoadAsync();
await Load();
System.Console.WriteLine("Finish");
}
public static void Main()
{
Test();
var i = 0;
while (true)
{
i++;
}
}
В таком — не можете
На самом деле, конечно, можете, для этого нужен простой набор комбинаторов поверх ContinueWith
ReadToEndAsync начинает чтение из подлежащего ридера не дожидаясь никакого await.
Никак вам не различить эти ситуации. То, когда начнется выполнение, зависит от того, что внутри AnyTask, а не снаружи.Если правильно понимаю вас, то при наличии интерфейса, как у меня, и абстрагируясь от конкретной имплементации документа, мне нужно явно указывать await у Load, чтобы гарантированно выполнить таск, верно? Или чего-то ещё не понимаю?
А если он не влияет — то и гарантировать ничего не может.
Если код чужой — смотреть в документацию.
Если таск вернули но он никогда не выполнился — ну что поделать, баг однако. Иногда баги случаются.
Последнее уточнение, для случая
...ForEach(async d => await d.Load())компилятор сгененирует ощутимо менее оптимальный код, чем для
...ForEach(d => d.Load()), поэтому второй вариант предпочтительнее? Или дело в другом?Там еще может случиться захват и возврат на контекст синхронизации, а вот это уже больно.
...ForEach(async d => await d.Load())мне срузу становится ясно, что загрузка идёт асинхронная, а вот
...ForEach(d => d.Load())ни о чём не говорит, нужно лезть в имплементацию или заранее именовать методы, как LoadAsync (при условии, что это мой код, а не чужой).
Из этих соображений читаемости для меня сейчас всё равно предпочтительным остаётся первый вариант…
Просто дело вот в чём, когда я вижу в коде конструкцию (например, на гитхабе) ForEach(async d => await d.Load()) мне срузу становится ясно, что загрузка идёт асинхронная, а вотВот только она не обязательно асинхронная.
а вот ForEach(d => d.Load()) ни о чём не говоритИменно поэтому асинхронные методы следует именовать Async.
Из этих соображений читаемости для меня сейчас всё равно предпочтительным остаётся первый вариант
Я не удивлен.
async...await человек понимает, что с тасками идёт работа.В случае же
LoadAsync, можно подумать, что я вообще по старинке вручную создаю поток без всяких тасков.Как-никак увидев async...await человек понимает, что с тасками идёт работа.
Что, на самом деле, является лишним для него мусором, потому что важно не то, идет ли работа с тасками, а то, идет процесс синхронно или асинхронно. А вот это, как я написал в первом же комменте по поводу этой строчки, нифига не очевидно, пока не заглянешь внутрь метода.
В случае же LoadAsync, можно подумать, что я вообще по старинке вручную создаю поток без всяких тасков.
А какая разница, если наблюдаемое поведение неотличимо?
По умолчанию принято считать что любой таск когда-нибудь выполнится если только обратное не написано в документации.
то для меня вдвойне очевидно, что загрузка выполнится асинхронно в случае работы с тасками, потому что никаких WaitAll я не делаю. А поскольку и в других местах используются подобные конструкции, например, с Close (где её убрать нельзя), то для общности мне хочется оставить её и с Load, путь даже это чуть менее оптимально с точки зрения компиляции.
Конечно, если вы видите более серьёзные потенциальные проблемы в виде блокировок, например, то поделитесь…
то для меня вдвойне очевидно, что загрузка выполнится асинхронно в случае работы с тасками
Для вас, возможно, очевидно. Для человека, который читает код, и видит в нем ForEach, и не знает, что внутри этого ForEach, есть сильно больше одного варианта происходящего. Вам продемонстировать?
static Task ForEach<T>(IEnumerable<T> source, Func<T,Task> f)
{
return Task.WhenAll(source.Select(f));
}
static async Task ForEach<T>(IEnumerable<T> source, Func<T,Task> f)
{
foreach(var s in source)
await f(s);
}
static void ForEach<T>(IEnumerable<T> source, Func<T,Task> f)
{
Task.WhenAll(source.Select(f)).Wait();
}
static void ForEach<T>(IEnumerable<T> source, Func<T,Task> f)
{
foreach(var s in source)
f(s).Wait();
}
… а, и это еще не считая пофигистичного варианта:
static void ForEach<T>(IEnumerable<T> source, Func<T,Task> f)
{
foreach(var s in source)
f(s);
}foreach для коллекций на метод, как у List'а, а, во-вторых, возможность вернуть коллекцию дальше в цепочку вызовов.Конкретно таски она затрагивает лишь косвенно. С таким же успехом я мог бы использовать стандартный метод класса
List и писать в нём async...await.Я учёл ваши замечания насчёт
Load и переписал через WhenAll. Теперь всё работает параллельно и асинхронно (при добавлении рандомных задержек в метод, прогресс-бары скрываются в разные моменты времени для каждого документа). Одобряете такой код?С таким же успехом я мог бы использовать стандартный метод класса List и писать в нём async...await.
… и они бы там игнорировались.
Одобряете такой код?
С async void методом-то? Спасибо, нет.
Кстати, на практике асинхронно и параллельно у меня работают и все вариации с ForEach (c async и без, у List и как своё расширение).
В каком смысле игнорировались?
На самом деле, я не прав, и у вас бы просто не скомпилировалось — насколько я помню, Func<T,Task> не приводим к Action<T>.
Кстати, на практике асинхронно и параллельно у меня работают и все вариации с ForEach
Это ровно до тех пор, пока у вас вызываемые внутри методы ведут себя определенным образом.
Documents.ForEach1(d => d.Expose())
.ToList().ForEach(async d => await d.Load());
Documents.ForEach1(d => d.Expose())
.ToList().ForEach(d => d.Load());Асинхронность отслеживаю визуально по состоянию прогресс-баров. Задержки добавляю случайно в классе PlainTextDocument
private static Random rand = new Random();
private async Task<bool> AsyncLoad()
{
await Task.Delay(3000 + rand.Next()%10000);
return (Model = _originalModel = (await GetKey()).Is(out var key)
? await Wrap.Storage.LoadText(key, EncodingModel.Encoding)
: null).Put(key.Is());
}Можете сами перепроверить, если мои результаты не внушают доверия. Для этого скомпилируйте и запустите приложение, создайте пять-десять документов, закройте через команду «Выход», а затем переоткройте и понаблюдайте за прогресс-барами, которые отображают процесс загрузки на вкладке каждого документа.
await Task.Delay(3000 + rand.Next()%10000);Муа-ха-ха. Замените это же на Thread.Sleep.
А это не шутка, это наглядная демонстрация того, что весь ваш код "асинхронен и параллелен" ровно до того момента, пока какой-нибудь вызываемый метод не начинает вести себя плохо.
Вы делайте, как хотите, а я лучше сразу обнаружу проблему и исправлю.
А вы мне предлагаете как ни в чём ни бывало игнорировать зависший или по ошибке медленно работающий таск
Эээ… нет, не предлагаю.
Вы делайте, как хотите, а я лучше сразу обнаружу проблему и исправлю.
Это говорит человек, который как не проверял статус тасков, так и не проверяет?
Task Load() блокирующий вызов Thread.Sleep(2000) или вызов с долгими вычислениями, например, то статус таска мне мало о чём скажет.При вашем подходе, например, даже с
WhenAll, программа у меня запустится, но поскольку UI не заблокируется, мне будет казаться, что это документы у меня так долго загружаются, может, оно так и нужно, связь, например, плохая с удалёным сервером при скачивании файла.При моём подходе сразу начнёт тормозить UI, что явно сигнализирует о каких-то проблемах в асинхронных методах.
Резюмируя всё вышесказанное, я действительно заблуждался в том, что await гарантирует запуск даже холодного таска и что его нельзя убрать в критикуемом случае с Load. В остальных моментах моё интуитивное понимание тасков позволило мне написать вполне рабочий код, пусть не самый оптимальный, но и не такой уж медленный.
При вашем подходе
Это при каком конкретно?
При моём подходе сразу начнёт тормозить UI
Это при каком конкретно? А то вы их меняете на ходу.
Хотя, проверил, и с WhenAll интерфейс тоже блокируется при Thread.Sleep, просто я не был уверен в имплементации этого метода, думал, что он обернёт всё в новый таск и Thread.Sleep не будет заметен.
Ошиблись оба раза, ни подход с WhenAll, ни подход с вызовом без ожидания не гарантируют ни параллельного выполнения, ни блокировки при задаче, в которой есть неэффективный код — для нарушения первого достаточно поставить неэффективный код до возвращения Task из задачи, для нарушения второго — после.
Уже думаю, может, лучше вернуться к старому доброму ручному созданию потоков с примитивами синхронизации… или, если код уже работает как надо, всё же решать проблемы с тасками по мере их поступления, а не заботиться о гиптетических случаях со сменами контекста или внезапными Thread.Sleep…
Уже думаю, может, лучше вернуться к старому доброму ручному созданию потоков с примитивами синхронизации…
Лучше вряд ли получится, но в .Net есть другие либы для работы с асинхронностью, где всё чуть более детерминированно — F# Async (и к нему в нагрузку AsyncSeq), Hopac (и туда же Hopac.Streams)
Ещё как вариант Rx.Net, для UI норм
И упомяну Akka.Net (и Akka.Streams) — универсальный солдат, работает на тасках, шедулеры там вроде свои написаны, но модель акторов абстрагирует от большей части дичи связанной с TPL
Уже думаю, может, лучше вернуться к старому доброму ручному созданию потоков с примитивами синхронизации…
На самом деле, если нужна гарантия выполнения в другом потоке — достаточно вызвать Task.Run(...)
Хотя на самом деле такая гарантия нужна не часто, обычно разумным является предположение о том что вызываемый метод не будет выполнять блокирующих операций в текущем потоке (а если вдруг будет — то это баг и его надо чинить на стороне вызываемого метода)
Чем больше информации узнаю из дискуссии про таски, тем больше поражаюсь их ненадёжности — никаких гарантий!
Они не более ненадежны, чем тот код, который их возвращает. Сами-то таски весьма просты.
Уже думаю, может, лучше вернуться к старому доброму ручному созданию потоков с примитивами синхронизации…
А ничего не изменится, пока вы сохраняете свою декомпозицию, только количество ручного кода вырастет.
гиптетических случаях со сменами контекста
Знаете ли, если у вас в UI-приложении смена контекста — это гипотетический случай, то я даже и не знаю, что сказать. Я-то думал, там это происходит регулярно.
внезапными Thread.Sleep
… и только что вы писали "я лучше сразу обнаружу проблему и исправлю". Вы уж определитесь.
… и только что вы писали «я лучше сразу обнаружу проблему и исправлю». Вы уж определитесь.
Писал я про то, что предпочитаю код, который сразу падает или зависает, если что-то перемудрили, а не пытается обработать или засупрессить все-все-все вероятные и маловероятные замысловатые ошибки, которые потенциально могли бы произойти, если бы.... умный человек разработал очень умный метод, работающий в зависимости от фазы луны и положения солнца.
Проще говоря, критикуемый
.ForEach(async d => await Load())
вполне работоспособное и безопасное решение, содержащее не больше подводных камней, чем сама реализация тасков. Если для кого-то такое решение выглядит неочевидным, то можно применить любое другое на свой вкус.
Да, в конкретном случае ключевые слова async...await опциональны, но для общности с другим кодом и лучшей читаемости допустим и такой вариант.
Ересь. У вас другой код решает другую проблему и решает её иначе — нет между ними никакой общности, кроме вашего желания копипастить.
Ересь. У вас другой код решает другую проблему и решает её иначе — нет между ними никакой общности, кроме вашего желания копипастить.
У меня отличное мнение от вашего. Сейчас мне не важен результат выполнения метода Load, но в обозримой перспективе он вполне может пригодиться, как показано в примере ниже. Поэтому некоторую общность я наблюдаю и стараюсь сохранить.
.ForEach(async d => await d.Close() && Documents.Remove(d))
.ForEach(async d => await d.Load())
.ForEach(async d => await d.Load() && RecentDocuments.Add(d))
но в обозримой перспективе
YAGNI
Пока Вы будете результат вкручивать, все равно пять раз перепишите. То, что вы написали работать не будет
То, что вы написали работать не будет
Отчего же не будет?
.ForEach(async d => await d.Close() && Documents.Remove(d))
уже прекрасно работает.
Если вы имеете в виду, что Add возвращает не bool, то да, здесь я поторопился, но суть примера это не сильно меняет, код больше для того, чтобы проиллюстрировать некоторую общность обоих случаев, а понадобится ли подобное расширение в дальнейшем или нет, уже другой вопрос.
Суть в том, что когда (и если) вы это напишите (и протестируете), тогда, может быть(!), там будет какая-то общность. И дописать async-await там — самое простое.
А пока там копипаста с WTF-эффектом и оправданием.
При ответах же на комментарии, которых довольно много, я не всегда компилирую примеры, поэтому могут возникнуть огрехи, но суть примеров всё же стараюсь сохранять.
Конечно, здорово, что люди критикуют, ведь сам я много не знаю и могу упустить важное, но на некоторые вопросы могут сосуществовать разные точки зрения. И тут нет правильных и неправильных, просто есть варианты, — хотите, применяйте WhenAll, хотите, ForEach, что вам ближе.
функционирует полностью исправно в соответствии с моими ожиданиями и интуицией
WTF эффект, конечно, не на собственном коде проявляется.
У кода есть 2 функции (минимум) — исполняться в соответствии с вашими ожиданиями, и быть читаемым другими людьми. А «применяйте что вам ближе» второй части, мягко говоря, не помагает.
А код, написанный «для себя» по определению хуже.
Проще говоря, критикуемый
.ForEach(async d => await Load())
вполне работоспособное и безопасное решение,
Оно "безопасно" тогда и только тогда, когда код внутри Load не бросает эксепшн. И вы об этом, опять-таки, никогда не узнаете, потому что никакого "сразу падает" или "сразу зависает" не будет.
На самом деле как раз "сразу падает" и будет если параметр ForEach — Action, а не Func<Task>
Не совсем так.
static void Main(string[] args)
{
Console.WriteLine("Starting");
try
{
new []{"1", "2"}.ForEach(async i => await Some(i));
Console.WriteLine("After ForEach");
}
catch (Exception e)
{
Console.WriteLine("Exception in ForEach: " + e);
throw;
}
Console.WriteLine("After catch");
Console.ReadLine();
Console.WriteLine("Finished");
}
static async Task Some(string item)
{
Console.WriteLine($"{item}: starting");
await Task.Yield();
Console.WriteLine($"{item}: after Yield");
await Task.Delay(3000);
Console.WriteLine($"{item}: after Delay, throwing");
throw new InvalidOperationException(item);
}Результат:
Starting
1: starting
2: starting
After ForEach
After catch
1: after Yield
2: after Yield
2: after Delay, throwing
1: after Delay, throwing
Unhandled ExceptionОбратите внимание: ForEach уже прошел, и try...catch, в который он завернут — тоже. Эксепшн бросился где-то и когда-то, и то, будет ли он пойман системой, зависит от контекста и диспетчера (что и видно в комменте ниже, где эксепшн никак не проявился в таком сценарии).
А теперь заменим ForEach(async i => await Some(i)) на ForEach(i => Some(i)):
Starting
1: starting
2: starting
After ForEach
After catch
1: after Yield
2: after Yield
2: after Delay, throwing
1: after Delay, throwing
FinishedЭксепшн вообще не пойман.
Оно «безопасно» тогда и только тогда, когда код внутри Load не бросает эксепшн. И вы об этом, опять-таки, никогда не узнаете, потому что никакого «сразу падает» или «сразу зависает» не будет.
Во-первых, в конкретном случае архитектурно задумано, что обработкой исключений занимаются сами документы, а в задачи главной вью-модели входят лишь вызовы интерфейсных методов.
Во-вторых, если всё же нужно обработать исключение, то тут как раз-таки обязательно нужны async...await, чтобы оно не прошло незамеченным мимо
.ForEach(async d =>
{
try { await Load(); }
catch (Exception e) { Debug.WriteLine(e); }
})
что, вероятно, подразумевалось в комметарии
На самом деле как раз «сразу падает» и будет если параметр ForEach — Action, а не Func
Однако отмечу, что в обоих случаях
.ForEach(async d => await Load())
.ForEach(d => Load())у меня исключение проигнорировалось.
Если же необходимо обрабатывать сразу агрегированную группу исключений, то стоит использовать WhenAll, в то время как ForEach позволяет сосредоточиться на обработке каждого исключения индивидуально. Где это может иметь значение? Например, у нас ряд долговыполняющихся тасков, WhenAll выбросит исключение, лишь когда все они завершатся, что может занять продолжительное время, ForEach же будет выбрасывать исключения по мере выполнения каждого таска отдельно, не дожидаясь остальных.
Во-первых, в конкретном случае архитектурно задумано
Я и говорю: ваш метод сам по себе не "безопасен", он рассчитывает, что вызываемые им методы "безопасны".
Во-вторых, если всё же нужно обработать исключение, то тут как раз-таки обязательно нужны async...awaitНет, достаточно сделать так, чтобы ForEach собирал результаты выполнения.
ForEach позволяет сосредоточиться на обработке каждого исключения индивидуально
Я не могу придумать сценария, где это нужно генерично (т.е., на уровне метода-расширения).
Я и говорю: ваш метод сам по себе не «безопасен», он рассчитывает, что вызываемые им методы «безопасны».
Согласен. Но это нормальная ситация в программировании иногда расчитывать на то, что метод безопасен, если так задумано изначально. Ведь никто же, как правило, не оборачивает
ToString() в try-catch, хотя исключение вполне может произойти даже при таком безобидном вызове.Нет, достаточно сделать так, чтобы ForEach собирал результаты выполнения.
В своём естественном применении ForEach ничего не собирает — это просто альтернатива классическому циклу foreach с некоторыми вариациями и бонусами. Конечно, можно исхитриться и что-то им собрать, но тогда уж лучше использовать другие методы-расширения из Linq.
Я не могу придумать сценария, где это нужно генерично (т.е., на уровне метода-расширения).
Вопрос здесь не в самом методе-расширении ForEach, поскольку он имеет нейтральную реализацию относительно тасков, а в способах его применения.
А пример может быть такой — менеджер закачек. Открываем приложение и в нашем методе-цикле возобновляем незавершённые загрузки. Если в какой-то происходит исключение, то не нужно ожидать, пока остальные завершатся, можно сразу обработать ситуацию.
Но это нормальная ситация в программировании иногда расчитывать на то, что метод безопасен, если так задумано изначально.
И чем это отличается от "расчитывать, что метод корректно ведет себя с точки зрения асинхронии"? Понимаете, вы пишете код, в котором есть некоторые неявные, никак не видимые из контракта предположения, но при этом считаете, что ваши предположения — уместны, а мои — нет. Хотя и те, и те вырастают из чтения кода.
В своём естественном применении ForEach ничего не собирает — это просто альтернатива классическому циклу foreach с некоторыми вариациями и бонусами.
Это неправда. В своем естественном применении ForEach выполняет примитивнейшую стратегию обработки ошибок "упади на первой ошибке". Вы применяете его для асинхронии (чего уже делать не стоит) и при этом ничего не делаете, чтобы сохранить эту стратегию.
Если в какой-то происходит исключение, то не нужно ожидать, пока остальные завершатся, можно сразу обработать ситуацию.
Или надо не запускать остальные, потому что исключение формата "у нас нет сети", и они все равно упадут. You never know.
(ну и да, такие вещи делаются без async по-хорошему, а на сообщениях или их имитации)
Вот вы видите впервые в коде With или ForEach с асинхронным делеготом, сразу вопрос — что это вообще такое и как оно работает? Начинаете разбираться, копаться, спорить, попутно узнаёте для себя что-то новое или вспоминаете позабытое… Разве это плохо?
И самое удивительное — всё это работает! И даже с хорошей производительностью. Да, при первой встрече такой код, возможно, окажется сюрпризом, насторожит, но когда вы его поймёте, то откроется его прелесть.
У меня нет цели писать специально под новичков, мне нравятся лямбды, дженерики, цепочные вызовы и прочие выразительные вещи, которые без определённого опыта сходу не поймёшь. Но это именно те вещи, которые заставляют думать и учиться, прививают вкус и чувство прекрасного в программировании.
Моя задача — просто делиться такими решениями с людьми, а каждый самостоятельно решит, насколько они ему подходят.
Спор у нас больше филосовского характера, вы стремитесь к «канонам»
Я стремлюсь к решениям, которые хорошо работают в команде в долгосрочной перспективе.
Вот вы видите впервые в коде With или ForEach с асинхронным делеготом, сразу вопрос — что это вообще такое и как оно работает? [...] Разве это плохо?
Да, это очень плохо, если речь идет о production-коде, при чтении которого вопросов "что это и как оно работает" должно быть как можно меньше и еще меньше.
У меня нет цели писать специально под новичков, мне нравятся лямбды, дженерики, цепочные вызовы и прочие выразительные вещи, которые без определённого опыта сходу не поймёшь.
Я, знаете ли, далеко не новичок, и ваш код все равно вызывает у меня вопросы. Если код вызывает вопросы у каждого члена команды, который его читает, это непроизводительно.
Но это именно те вещи, которые заставляют думать и учиться, прививают вкус и чувство прекрасного в программировании.
… точнее, то, что вы считаете вкусом и чувством прекрасного. Как можно видеть в дискуссии, не все с вами согласны.
сразу вопрос — что это вообще такое и как оно работает?
Ну вот, а вы говорите в вашем коде нет WTF-эффекта...
Если же при изучении всё наоборот становится на свои места, то тут нет никакого WTF-эффекта. По сути, согласно вашему определению, любой код обладает таким эффектом, например, я новичок и увидел впервые лямбды, конечно, первый вопрос, что это вообще такое? Но стоит их изучить, как сам уже применяю на практике, потому что с ними всё логично и лаконично…
Есть проблема не понимания новичком языка. Это проблема новичка.
А есть проблема непонимания опытными разработчиками конкретно вашего кода. Это проблема вашего кода.
Я бы мог потратить время на изучение вашего диалекта, но я его потратил на изучение тасков. И, простите, не жалею.
items.ToList().ForEach(async i =>
await DoSomething(i));
items.ToList().ForEach(async i =>
{
try { await DoSomething(i); }
catch (Exception e) { Debug.WriteLine(e); }
});у вас больших проблем возникнуть не должно. Тут даже не мой какой-то диалект, а стандартные средства языка позволяют так делать.
Не сомневаюсь, что вы потратили время с пользой, участвуя в дискуссии, однако если вы не слишком пытались изучить «мой диалект», ограничиваясь лишь беглым поверхностным рассмотрением, то делать выводы о его ценности конкретно для вас и особенно для других людей преждевременно. Вы вполне могли упустить суть некоторых вещей.
Если же вы изучите материалы подробно, тогда сможете более объективно оценить все их стороны и решить, полезены он вам или нет. Конечно, на это нужно потратить время, есть риск разочароваться, но пока вы, глубоко не вникая, отрицаете что-то новое и непривычное, ценность и польза этих знаний конкретно для вас неопределена.
Решений было предложено множество (To, With, Check, Put и другие паттерны), более того, в публикации и вовсе не шло речи про ForEach, но почему-то в расширенных примерах кода зацепились именно за него. :) Если же вам ничего из этого списка не пришлось по вкусу, то пользуйтесь своими решениями.
Многие эти штуки я использую не только в экспериментальных целях, но и на практике, мне они облегчают работу, поэтому решил поделиться с другими людьми, вот и всё, даже никого не призываю их использовать, просто предлагаю материал, над которым как минимум можно поразмышлять и пофантазировать…
Что бы что? Это спортивное фантазирование, оно разработку не ускоряет.
На мой взгляд, воображение и абстрактное мышление — важнейшие инструменты инженера-проектировщика. Поэтому их стоит поддерживать в тонусе даже из спортивного интереса.
Фантазирование развивает фантазирование. От фантазирования эффективность не растет.
Детям не дают заданий «придумайте необычный способ решения»
Детям не дают заданий «придумайте необычный способ решения»
Это и отичает способных учеников — неординарный подход к решению различных задач.
А вот не факт совершенно. Есть разные варианты "способных учеников", и не все из них подразумевают "неординарный подход".
(если не секрет, у вас есть педагогическое образование и/или опыт преподавания в учебном заведении?)
Это вам так хочется думать.
Повторяю, задач таких не ставят. Более того, за попытку посчитать интегрированием площадь треугольника по двум катетам есть все шансы получить кол за неусвоение темы урока.
Там надо в журнал формальную оценку поставить, варианта «и уж наверняка» там нет
Если бы попался человек, который умеет расчитываеть площадь треугольников интегрированием, но не знает классического, то я бы получше присмотрелся к нему и задал бы ряд уточняющих вопросов…
И, уж наверняка, сможет подсчитать площадь треугольника классическим способом.
Не, нет никакого "наверняка". Люди иногда забывают простейшие вещи.
Но ведь это не делает человека глупее или некомпетентнее, хотя формально вы могли завалить тест по C# из-за этого вопроса… Важно понимание сути самой темы. Задача оценивающего — выяснить, насколько близко подобрался к этому экзаменуемый.
Но ведь это не делает человека глупее или некомпетентнее
Некомпетентнее (по сравнению с тем, кто ответил на все те же вопросы и этот) — делает.
хотя формально вы могли завалить тест по C# из-за этого вопроса…
Формально — не мог. TPL не является частью C#.
Фантазирование развивает мышление
Можно увидеть ссылки на исследования, подтверждающие это?
И ещё такой момент — далеко не все области хорошо поддаются исследованиям и статистическому анализу. Естественные науки — да, но психология и творчество — это во многом субъективные мнения и зачастую противоположные точки зрения. Поэтому когда вы просите меня предоставить критерии оценки красоты или исследования о закономерностях развития мышления у людей, то вы просто забываете о том факте, что существуют явления в основе своей вероятностные и малоопределённые.
Мой жизненный опыт подтверждает это.
Ваш жизненный опыт — это пренебрежимо малая окрестность для нормального наблюдения.
И ещё такой момент — далеко не все области хорошо поддаются исследованиям и статистическому анализу.
Образование поддается и тому, и другому.
Поэтому когда вы просите меня предоставить [...] исследования о закономерностях развития мышления у людей, то вы просто забываете о том факте, что существуют явления в основе своей вероятностные и малоопределённые.
Тогда зачем вы делаете утверждения, которые невозможно ни проверить, ни опровергнуть?
Более того, исследования о закономерностях развития мышления существуют, это вполне себе область знания (и даже не одна).
Можно лишь выявлять корреляции и на их основе давать вероятностные прогнозы…
Ура. Так можно мне ссылку на исследование, показывающее статистически достоверную корелляцию между фантазированием и развитием мышления?
Собрали дошколят и говорят: «Дети! Мы будем проводить исследование по влиянию фантазирования на развитие вашего мышления! Теперь вы должны фантазировать строго по нашему расписанию на определённые темы на проятяжении пятнадцати лет, а попутно мы будем проводить разные-разные тесты… Для убедительности одну подгруппу мы ограничим в фантазировании, а другую будем стимулировать к этому… и т. д. и т. п.»
Или, может, сделать опросник для взрослых людей?
Как часто вы фантазированли в возрасте до пяти лет? До десяти?.. В какие игры играли? В какие кружки ходили? Сколько времени уделяли этим занятим? Какие книжки прочитали? Какие мультики посмотрели и по сколько раз? С кем дружили? Как часто гуляли?..
Или лучше возьмём близнецов, которых разлучили в детстве! Гениально! Изучим вляние среды на развитие близнецов…
Вот только даже в генетике, где всё чуть более детерменировано, чем в психическом развитии, исследования близнецов выявили ряд корреляций, оказашихся в последствии ошибочными… У Роберта Сапольского есть интересная лекция, где затронута тема исследования близнецов.
Как бы там ни было, для объективного исследования и детального прослеживания закономерностей настолько комплексных и фундаментальных явлений, как фантазирование и развитие мышления, на текущем этапе развития человечества невозможно воссоздать необходимые «чистые» условия. И вообще, хороший вопрос, возможно ли такое в принципе?..
Максимум, что сейчас нам доступно — это поиск очевиднейших корреляций, например, что набор определённых мутаций в генах серьёзно повышает риск возникновения дименции в старости или такие-то гены, ответсвенные за развитие речевых центров отличают нас от других приматов.
Вы же меня просите о невыполнимой вещи, предоставить вам ссылки на исследования, которых не существует. Современная формализованная наука только-только начинает соприкасаться с такими вещами. Другое дело — житейский опыт. Если с ребёнком достаточно заниматься, учить его, развивать, играть, стимулировать фантазию, то всё это способствует развитию его мышления! Да, не факт, что из ребёнка вырастет выдающийся учёный, но тенденции к тому, что человек будет образованный и развитый, намного больше.
Вы же меня просите о невыполнимой вещи, предоставить вам ссылки на исследования, которых не существует.
Значит, ваше утверждение выше ("Фантазирование развивает мышление") ничем не подтверждено. О чем и речь.
Если с ребёнком достаточно заниматься, учить его, развивать, играть, стимулировать фантазию, то всё это способствует развитию его мышления!
Может быть. Все вместе. Или только сам факт "заниматься с ребенком". Или вообще восьмой фактор, который вы не учли.
тенденции к тому, что человек будет образованный и развитый, намного больше.
… а если у человека (точнее, его семьи) больше денег — тоже шансов, что он вырастет образованный и развитый больше. Делаем вывод, что деньги развивают мышление?
Вы просто ответьте сами себе на такой вопрос. Представьте, что у вас есть ребёнок, проявляющий способности к чему либо… Вы можете пустить всё на самотёк и заниматься своими делами в удовольствие, а можете приложить некоторые усилия и способствовать развитию этих способностей у ребёнка, отдать его, например, на соответствующий кружок, поощерять прогресс, тратить ресурсы на это.
Конечно, здравый смысл и житейский опыт подсказывают, что второй вариант более благоприятный. Вы можете спорить до умопомрачения, что «здравый смысл» часто не работает, а «житейский опыт» обманывает, искать исследования на тему влияния детских кружков на мышление и прочее, и прочее… Но что это вам даёт? Уверенность? В чём?
Деньги — это косвенный и комплексный фактор фактор.
Фантазия — это тоже косвенный и комплексный фактор.
Представьте, что у вас есть ребёнок, проявляющий способности к чему либо [...] можете приложить некоторые усилия и способствовать развитию этих способностей у ребёнка
Дело в том, что надо подобрать именно те действия, которые будут реально способствовать развитию, а не просто абстрактное "это полезно".
Но что это вам даёт? Уверенность? В чём?
В том, что любые приемы по отношению к образованию надо проверять по отклику.
И это не говоря о том, что вы подменили простое утверждение "фантазия развивает мышление" существенно более сложным "заниматься с ребенком полезно для ребенка". Второе, при этом, настолько тривиально, что даже бесполезно обсуждать.
А вам что даёт форсинг часто не работающего «здравого смысла»?
то со стандартными конструкциями вида [...ForEach...] у вас больших проблем возникнуть не должно. Как раз наоборот, именно потому, что я знаю, как себя ведут таски, эти конструкции и вызывают у меня вопрос "какого хрена", потому что я знаю, как они себя поведут (после того, как я слазил в реализацию ForEach, чего тоже быть не должно), и это поведение для меня неприемлемо.
делать выводы о его ценности конкретно для вас и особенно для других людей преждевременно. Вы вполне могли упустить суть некоторых вещей.
Ну вот мы уже тут сколько дней переписываемся, а никакой добавленной ценности (или глубинной сути) так и не найдено.
Конечно, на это нужно потратить время, есть риск разочароваться,
… и что делать в этом случае?
Нет, WTF-эффект — это когда читаешь код, и задаешься вопросом "WTF?!". Все.
я новичок и увидел впервые лямбды, конечно, первый вопрос, что это вообще такое?
Есть разница между вопросом "что это такое" и "какого хрена".
По сути, согласно вашему определению, любой код обладает таким эффектом, например,
Нет, не любой. Есть разница между "я не знаю этой конструкции" и "эта конструкция — не то, что я ожидаю, хотя я знаю язык".
Поэтому никаких обманутых ожиданий такой код у меня не вызывает. Мне вообще не ясно, чем вам так запал в душу этот пример…
их поведение меня полностью устраивает и соответствует даже интуитивному пониманию.
Вас устраивает и соответствует вашему интуитивному пониманию.
Поэтому никаких обманутых ожиданий такой код у меня не вызывает.
Это неудивительно: его вы написали. Поэтому вас все устраивает, и все соответствует вашей интуиции. То, что ваша интуиция при этом не соответствует интуиции других людей (и, в том числе, реальному поведению системы в ряде ситуаций) — это вас не волнует.
Мне вообще не ясно, чем вам так запал в душу этот пример…
Тем, что он противоречит хорошему тону работы с асинхронией как я его понимаю.
1. Try — не генерирует исключений и возвращает bool
2. Async — асинхронный
Надеюсь, теперь будет понятнее.
Угу, теперь мы понимаем, что мы вызываем метод, который может завершиться неуспехом, и не дожидаемся его окончания. Круто.
Как было понятно, что на момент окончания вызова ForEach состояние дочерних моделей не определено, так и осталось.
Состояние определено после вызова Expose — остальное не имеет значения в данном контексте.
Или понимаем, что в конкретном случае совсем не важен результат выполнения метода, а важен лишь факт его вызова.
Именно это и пугает. Я бы понял, если бы у вас был явный message passing, но у вас же его нет.
Состояние определено после вызова Expose — остальное не имеет значения в данном контексте.
… не имеет значения, но написано. Тоже проблема.
Никак. Точно так же, как нет никакого способа быть уверенным, что вызываемый метод не бросит исключения.
Вы явно чего-то не понимаете. Выполнение кода не зависит от того, что вы делаете с полученным объектом Task.
«Эти интегралы слишком сложные, нужно приложить усилия, чтобы научиться их читать и понимать,
Простой вопрос: что будет, если я вызову CoreViewModel.Expose, а потом немедленно CoreViewModel.Documents.First().SaveAs()?
… и тот милый факт, что документ пустой только потому, что Load еще не завершился, вас никак не смущает?
И нормально, что в процессе загрузки (которая, например, может быть чанками) кто-то вызвал Save?
Для этого Save и асинхронный, если возникнет необходимость в такой загрузке, то Save будет внутри себя ожидать её завершения.
То есть документ должен внутри себя следить, идет ли у него процесс загрузки, и блокировать все остальные операции, пока этот процесс не завершился?
Вся логика работы с файлом (или группой фалов) инкапсулирована внутри самого документа.
Основной вью-модели или кому-то ещё вообще не нужно знать, как конкретно документ работает с файлами или даже какими-то другими ресурсами, а уж тем более какие ошибки могут при этом возникнуть и как их обрабатывать.
Documents.ForEach(d => d.Expose()).ForEach(async d => await d.Load());
Вас мое мнение интересует?
await Documents
.Select(d => {
d.Expose();
return d.Load();
})
.WaitAll(); .ContinueWith((a) =>Application.InvokeOnMain(()=> method())у меня выдает исключение, мол, не лезьте в другой поток.
Вам нужен правильный диспетчер, который вызовет ваш continuation на нужном потоке.
Где можно почитать подробнее об организации подобного диспетчера?
Его не надо организовывать, его вам система предоставляет. Рекомендую книгу Stephen Cleary, Concurrency in C# Cookbook.
public static void WaitAll(
params Task[] tasks
)Лучше назвать его WhenAll.
Да я и не сомневаюсь.
Просто это полная противоположность заявленному «провоцирует оформлять код мелкими методами с раздельной отвественностью»: ваш подход провоцирует вас писать крупные методы с ответственностями, спрятанными в цепочку вызовов.
Так вы говорите
Documents.CollectionChangeCompleted += (sender, args) =>
args.NewItems?.Cast<ADocument>().LastOrDefault()
.To(out var document)?.With(ActiveDocument = document);эстетичнее, прекраснее и чище, чем
Documents.CollectionChangeCompleted += (sender, args) =>
ActiveDocument = args.NewItems?.Cast<ADocument>().LastOrDefault()?
Надо заметить, кстати, что поведение этих двух вариантов — разное, и я вот еще не уверен, что знаю, какое правильное.
Думаю, так будет лучше видна разница в логике
Documents.CollectionChangeCompleted += (sender, args)
{
var document = args.NewItems?
.Cast<ADocument>().LastOrDefault();
if (document != null) ActiveDocument = document;
}По задумке не нужно менять активный документ, если, например, пользователь закрыл другой неактивный и сработало событие 'CollectionChangeCompleted'.
И вот то, что эта разница в логике на первый взгляд в коде незаметна, очень много говорит о читаемости и чистоте кода.
Ну то есть надо прилагать лишние усилия для чтения вашего "читаемого" кода. Спасибо, нет.
Знаете, ваша позиция напоминает мне такую: «Эти интегралы слишком сложные, нужно приложить усилия, чтобы научиться их читать и понимать, лучше я буду пользоваться школьной математикой». )
Без труда — не вытащишь и рыбку из пруда.
Ну так надо же сначала понять, зачем мне эта рыбка. В некоторых прудах, знаете ли, лучше ничего не ловить.
Знаете, ваша позиция напоминает мне такую: «Эти интегралы слишком сложные, нужно приложить усилия, чтобы научиться их читать и понимать, лучше я буду пользоваться школьной математикой».
Знаете, мне пока ни разу в обыденной жизни не были нужны интегралы.
А если они мне не нужны, то зачем мне их уметь читать и понимать?
Просто ваша призыв выглядит сейчас так: «Не учите интегралы, они трудные, с ними легко ошибиться, и они, наверняка, не пригодятся вам в жизни. Пользуйтесь школьной математикой, она простая, понятная, хорошо применима на практике, и многие ей хорошо владеют».
expression-bodied [...] развивает чувство прекрасного
Доказательства в студию. Вот прямо начиная с объективного определения чувства прекрасного и метода его определения.
Если бы не эта математическая красот
"Математическая красота" — это то отстутствие побочных эффектов (вытекающее из правила подстановок), на которое вы забили?
Ваш код можно переписать и без использования дополнительного сахара:
var p = GetPerson();
p.FirstName.To(out var oldFirstName);
p.FirstName = "Иван";
p.LastName = "Пупкин";
var personStringView = p.ToString();
var manager = p;Так что, кроме методов-выражений полезности почти никакой.
var p = new Person();
p.FirstName = "Иван";
p.LastName = "Пупкин";var p = new Person
{
FirstName = "Иван",
LastName = "Пупкин"
}Может, это и не самая остро необходимая функция языка, но мне она весьма по душе. :)
Обычно сахар вводят для уменьшения видимого размера кода.
Автосвойства позволяют не писать backing field.
Делегаты создаются неявно.
async/await позволяет 2 словами заменить целую машину состояний и ручную работу с продолжениями.
Конечно, было бы здорово получить синтаксический сахар на нативном уровне вроде
GetPerson()?.With
{
.FirstName = "Иван",
.LastName = "Пупкин"
}.DoSomething();но это вопросы к разработчикая языка. Я вносил подобные предложения, но дизайнеры уже приняли ряд весьма неоднозначных реший, первое из которых уже в релизе
IModel GetModel() => ...
/* true|false */
GetModel() is IModel m
/* always true */
GetModel() is var mДалее предполагаются
/* true|false */
GetModel() is {} m // null check
/* true|false */
GetModel() is {Name is {} s, City is var c} mне знаю, как для вас, но для меня более очевидны такие формы
/* true|false */
GetModel().Is(out var m) // null check
/* true|false */
GetModel().Is(out var m) && m.Check
(
m.Name.Is(out var s), // null check
m.City.To(out var c).Put(true)
).All(true)GetPerson()?.With
{
.FirstName = "Иван",
.LastName = "Пупкин"
}.DoSomething();
А вот это у вас вообще что делает? Ну, в бизнесовом смысле. Вы (не)получаете человека, что-то меняете и, может быть, делаете запрошенное пользователем действие? У вас, кажется, много логики на null без обработки проблем...
GetPerson()?.MethodA().MethodB();У меня примерно в 100% случаев появление null требует или обработки ошибки, или появления fallback value перед вызовом MethodB. То есть такой цепочки просто не появляется.
Вот и вопрос, то ли у меня задачи не такие, то ли это ваши эксперименты ради экспериментов.
То есть, у вас тоже нет живого примера того, что «было бы здорово получить» — в реальной жизни это не нужно. И, соответственно, в C#, ради такого, сахар добавлять не надо.
/* true|false */
GetModel() is {} m // null check
/* true|false */
GetModel() is {Name is {} s, City is var c} mЭто явная проверка, а не цепочечный метод.
(и это не какой-то "Check-паттерн", а обычный паттерн-матчинг).
Если бы мне в нём всё сразу понравилось, то никаких альтернатив точно бы не изобретал.
Конечно, было бы здорово получить синтаксический сахар на нативном уровне вроде
GetPerson()?.With { .FirstName = "Иван", .LastName = "Пупкин" }.DoSomething();
Вот только в этот момент непонятно, что такое With с точки зрения синтаксиса.
не знаю, как для вас, но для меня более очевидны такие формы
А для меня более очевиден обычный паттерн-матчинг.
Вот только в этот момент непонятно, что такое With с точки зрения синтаксиса.
Что-то наподобие инициализационного блока с дополнительным префиксом и доступом к контексту через '.'
Инициализационный блок не может быть вызван как метод.
нельзя без замыканий выводить значения в новые переменные (производить деконструкцию объекта)Это я даже назвал плюсом) Польза появления новых переменных по умолчанию сомнительна, кмк.
нет возможности удобно модифицировать структуры
public delegate void ActionRef<T>(ref T obj);
public static T With<T>(this T obj, ActionRef<T> initializer) where T: struct {
initializer(ref obj);
return obj;
}
// Как и было
public static T With<T>(this T obj, Action<T> initializer) where T: class {
initializer(obj);
return obj;
}
...
struct Person { ... }
var manager = GetPerson().With((ref Person o) => {
o.FirstName = "Иван";
o.LastName = "Пупкин";
});больше скобок и меньше похоже на инициализационные блокиЗато меньше методов чейнится и меньше похоже на колдунство)
Наверное я старомоден, но это какой-то садомазохизм: главное в коде не количество строк, а простота. Когда можно понять код, без чтения 10-страничных пояснений… Все началось с элементарного присваивания, продолжилось интуивно понятным JSON, а закончилось галиматьей. Назвать это синтаксическим сахаром, это мягко говоря, преувеличить. Могу представить подобную простынку кода для сопровождения и не дай бог модификации…
Да, подход новый и непривычный, но после десяти минут внимательного и вдумчивого изучения всё становится на свои места и в дальнейшем не вызывает трудностей.
Конечно, это ваше дело, использовать или нет подобные решения. Всего лишь делюсь личным опытом с другими людьми. Каждый сам решит, насколько ему это пригодно.
int val = (Int32.TryParse( «12», out val)? val: -1 );
Актуальные примеры синтаксиса и/или модели языка, которые часто используются, но могли бы быть сделаны лучше — начиная от приведения типов и далее.
Но сделано как сделано — по историческим причинам, вроде совместимости с C-синтаксисом.
А вот как это обходить — вопрос.
В приведенных способах есть свои недостатки:
- Используются конструкции языка, которые предназначены для другого, но особенности которых позволяют, пользуясь определенными паттернами, достичь нужного результата. При этом страдает читаемость и масштабируемость (потому что за эти паттернами еще нужно увидеть модель), хотя ради них — читаемости/масштабируемости все и затевалось.
- Те паттерны, которые выненесены в свои "велосипеды" — получается, их нужно тащить из проекта в проект, обеспечивать версионность и прочее. А ведь потом все равно поймешь, что можно было сделать лучше или универсальнее, или новые конструкции языка появятся, которые можно использовать напрямую, или которые позволят радикально упростить "велосипед".
- Есть ли уверенность, что подобные вещи, помещаемые в проектах в сборки типа "Common" (коих легион), действительно обеспечивают поддержку всех кейсов использования (на то они и "Common")?
- И как в командах обеспечивать соблюдение решений типовых ситуаций всегда с использованием велосипедов? (а если половина будет сделано так, другая эдак, то и смысл теряется)
В общем, хороший труд, но на своем опыте я пришел к тому, что при разработке прикладного продукта лучше использовать стандартные средства языка/платформы/фреймворков, если только вы сами не пишите продукт, который является фреймворком и предназначен для использования в других продуктах.
Лучшее применение таких опытов, как в статье — использование результатов исследований для предложения новых фич в языке/платформе, или даже для разработки нового языка.
Насколько понимаю, тот же Kotlin и появился в результате всестороннего обдумывания, как каждую из уже известных в языках фич сделать с нуля так, чтобы каждая фича действительно была пригодна для использования по назначению, и ее применение в коде было бы наиболее простым и интуитивно понятным.
Проект Ace — это набор базовых библиотек, которые я использую в качестве основы для других своих проектов. Своего рода экстракт моих наработок и знаний за годы активного программирования.
Что касается синтаксической части библиотеки — это во многом исследовательская работа, способ взглянуть на язык с нового ракурса, поиск путей развития.
Возможно, есть люди, которым такое тоже интересно, а статья послужит поводом для переосмысления даже таких фундаментальных вещей, как присваивание и передача параметров в методы.
– Долгая история. Все дело в том, что местные программисты пошли по неверному пути. Этот путь называется объектно ориентированный подход в программировании. На самом деле это мина с часовым механизмом в красивой упаковке. В очень красивой упаковке. Как с этим бороться, я не знаю. Упустил момент.
– Мастер, ближе к делу.
– Знаешь анекдот, как программист кипятит чайник. Дано: пустой чайник, кран, спички, газовая плита. Программа действий: наполнить чайник водой из-под кран
а, поставить на плиту, зажечь газ. Ждать, пока закипит чайник. Эта программа оформляется как объект. Второй случай. Все то же самое, но чайник с водой уже стоит
на плите. Действия программиста: вылить воду из чайника и выполнить предыдущий
объект.
– Грустно. А нырнуть внутрь объекта нельзя? Туда, где надо газ зажечь?
– Нельзя. Можно добавить новое свойство или действие. В нашем случае – вод
у вылить. Будет новый объект. Но внутрь влезть нельзя. Объект дается как единое
целое. Никто не знает, что там внутри. Все давно забыли, откуда ноги растут. В результате получается колоссальное дублирование кода и данных и огромная потеря производительности компьютера. С каждым годом компьютеры требуют все больше памяти, а работают все медленнее.
(с)
Каждый подход имеет свои преимущества и недостатки, которые делают его более оптимальным или неоптимальным для тех либо иных задач. Равно как в определённых условиях одни виды жизни более успешны, чем другие, а в других условиях — наоборот.
Многообразие — важный механизм эволиции. )
и ещё и усложнение структуры чтения языка, например когда я имею дело несколько раз на дню с разными языками программирования переключать мозг в режим распознавания диалекта и особенностей конструкций например типа "=>" в разных языках обозначающей разное и способствующей только сокращению нажатий кнопки на клавиатуре (хотя интели-сенс уже в практически любых иде есть), но ухудшающей общее восприятие кода — я считаю это деградацией.
и да, я специально убрал под спойлер.
p.s. «я слишком стар для всего этого дерьма...» © )
var person = CreatePerson().To(out var p)?.With
(
p.Name = "Abc",
p.Age = 28,
p.City.To(out var c)?.With
(
c.Name = "Minsk"
)
);
Вы какую-то синтаксическую соль придумали, наивная реализация оказывается гораздо элегантнее и проще:
var person = CreatePerson();
person.Name = "Abc";
person.Age = 28;
person.City.Name = "Minsk";
var person = new Person
{
Name = "Abc",
Age = 28,
City = new City { Name = "Minsk" }
}Одна из базовых фишек With-метода — сохранение структуры кода, если
new Person заменить на CreatePerson(). Конечно, на простых примерах это преимущество не столь очевидно, но при возрастании сложности разница становится заметна, особенно с учётом проверок на null (?.).Но всё же наиболее интересные бонусы — вызов методов и возможность одновременной инициализации и деконструкции объектов.
lair провёл бенчмарки и получил разницу примерно в 5 раз по сравнению с инициализационными блоками в худшую сторону. Однако, как справедливо заметил SENya1, lair воспользовался неоптимизированной перегрузкой метода, вызывающей боксинг и аллокацию массивов,
public static T With<T>(this T o, params object[] pattern) => o;вместо
public static T With<T>(this T o) => o;
public static T With<T, A>(this T o, A a) => o;
public static T With<T, A, B>(this T o, A a, B b) => o;
public static T With<T, A, B, C>(this T o, A a, B b, C c) => o;
/* ... */У SENya1 на оптимизированном методе получилась разница уже порядка двух раз в пользу инициализационных блоков.
Как говорится, доверяй, но проверяй. Мне стало интересно, каковы будут результаты на моей конфигурации и повлияет ли на производительность аттрибут
[MethodImpl(MethodImplOptions.AggressiveInlining)].За основу я взял слегка модифицированный код lair 'а и проверил его на
.NET Framework 4.7.1 (CLR 4.0.30319.42000), 32bit LegacyJIT-v4.7.2633.0
.NET Core 2.0.3 (CoreCLR 4.6.25815.02, CoreFX 4.6.25814.01), 64bit RyuJITusing System;
using System.Runtime.CompilerServices;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Attributes.Columns;
using BenchmarkDotNet.Attributes.Exporters;
using BenchmarkDotNet.Attributes.Jobs;
using BenchmarkDotNet.Running;
namespace Benchmarking
{
internal class Program
{
static void Main(string[] args)
{
try
{
BenchmarkRunner.Run<WithAndWithout>();
Console.WriteLine("Done");
}
catch (Exception e)
{
Console.WriteLine(e);
Console.ReadKey(true);
}
}
}
static class LE
{
//[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static T To<T>(this T o, out T x) => x = o;
//[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static T With<T, A, B>(this T o, A a, B b) => o;
}
public class Person
{
public string Name { get; set; }
public int Age { get; set; }
}
public class WithAndWithout
{
private readonly string _name = Guid.NewGuid().ToString();
private readonly int _age = 42;
[Benchmark] public Person With() => new Person().To(out var p).With
(
p.Name = _name,
p.Age = _age
);
[Benchmark] public Person Without() => new Person
{
Name = _name,
Age = _age
};
}
}BenchmarkDotNet=v0.10.14, OS=Windows 10.0.16299.371 (1709/FallCreatorsUpdate/Redstone3)
Intel Core i7-3517U CPU 1.90GHz (Ivy Bridge), 1 CPU, 4 logical and 2 physical cores
Frequency=2338444 Hz, Resolution=427.6348 ns, Timer=TSC
[Host] : .NET Framework 4.7.1 (CLR 4.0.30319.42000), 32bit LegacyJIT-v4.7.2633.0
DefaultJob : .NET Framework 4.7.1 (CLR 4.0.30319.42000), 32bit LegacyJIT-v4.7.2633.0
Method | Mean | Error | StdDev |
-------- |---------:|----------:|----------:|
With | 16.77 ns | 0.5297 ns | 0.4955 ns |
Without | 16.44 ns | 0.6119 ns | 0.7284 ns |
Method | Mean | Error | StdDev |
-------- |---------:|----------:|----------:|
With | 17.40 ns | 0.6391 ns | 0.7849 ns |
Without | 16.52 ns | 0.5868 ns | 0.5489 ns |
BenchmarkDotNet=v0.10.14, OS=Windows 10.0.16299.371 (1709/FallCreatorsUpdate/Redstone3)
Intel Core i7-3517U CPU 1.90GHz (Ivy Bridge), 1 CPU, 4 logical and 2 physical cores
Frequency=2338444 Hz, Resolution=427.6348 ns, Timer=TSC
.NET Core SDK=2.0.3
[Host] : .NET Core 2.0.3 (CoreCLR 4.6.25815.02, CoreFX 4.6.25814.01), 64bit RyuJIT
DefaultJob : .NET Core 2.0.3 (CoreCLR 4.6.25815.02, CoreFX 4.6.25814.01), 64bit RyuJIT
Method | Mean | Error | StdDev |
-------- |---------:|----------:|----------:|
With | 20.06 ns | 0.6929 ns | 0.6142 ns |
Without | 20.71 ns | 0.5962 ns | 0.4979 ns |
Method | Mean | Error | StdDev |
-------- |---------:|----------:|----------:|
With | 20.42 ns | 0.5245 ns | 0.4379 ns |
Without | 20.65 ns | 0.6069 ns | 0.5068 ns |
BenchmarkDotNet=v0.10.14, OS=Windows 10.0.16299.371 (1709/FallCreatorsUpdate/Redstone3)
Intel Core i7-3517U CPU 1.90GHz (Ivy Bridge), 1 CPU, 4 logical and 2 physical cores
Frequency=2338444 Hz, Resolution=427.6348 ns, Timer=TSC
[Host] : .NET Framework 4.7.1 (CLR 4.0.30319.42000), 32bit LegacyJIT-v4.7.2633.0
DefaultJob : .NET Framework 4.7.1 (CLR 4.0.30319.42000), 32bit LegacyJIT-v4.7.2633.0
Method | Mean | Error | StdDev |
-------- |---------:|----------:|----------:|
With | 16.52 ns | 0.5420 ns | 0.5070 ns |
Without | 15.89 ns | 0.4229 ns | 0.3955 ns |
Method | Mean | Error | StdDev |
-------- |---------:|----------:|----------:|
With | 21.09 ns | 0.6985 ns | 0.7173 ns |
Without | 18.68 ns | 0.4569 ns | 0.4050 ns |
BenchmarkDotNet=v0.10.14, OS=Windows 10.0.16299.371 (1709/FallCreatorsUpdate/Redstone3)
Intel Core i7-3517U CPU 1.90GHz (Ivy Bridge), 1 CPU, 4 logical and 2 physical cores
Frequency=2338444 Hz, Resolution=427.6348 ns, Timer=TSC
.NET Core SDK=2.0.3
[Host] : .NET Core 2.0.3 (CoreCLR 4.6.25815.02, CoreFX 4.6.25814.01), 64bit RyuJIT
DefaultJob : .NET Core 2.0.3 (CoreCLR 4.6.25815.02, CoreFX 4.6.25814.01), 64bit RyuJIT
Method | Mean | Error | StdDev |
-------- |---------:|----------:|----------:|
With | 21.49 ns | 1.6874 ns | 2.8193 ns |
Without | 20.51 ns | 0.7460 ns | 0.7982 ns |
Method | Mean | Error | StdDev |
-------- |---------:|----------:|----------:|
With | 20.97 ns | 0.7592 ns | 0.7457 ns |
Without | 21.14 ns | 0.7364 ns | 0.7562 ns |
Результаты на моей конфигурации показали, что код с использованием оптимизированного With практически неотличим по производительности от инициализационных блоков! Причём, атрибут
AggressiveInlining не оказывает видимого влияния на результаты.Бенчмаки запускал по много раз, заметил, что результаты могут плавать, особенно, если во время тестов загружать процессор, например, открывать браузер или запускать другие ресурсоёмкие задачи (возможно, этим объясняется большое отклонение, полученное SENya1).
Конечно, было бы интересно сравнить результаты и на других конфигурациях… На текущий момент, полученные мной, результаты демонстрируют, что оптимизированной версией расширения можно пользоваться безо всяких опасений насчёт снижения производительности.
Согласен с impwx и lair очень неоднозначные конструкции получились. Неверное, больше всего не нравится, что добавляются переменные в область видимости, и это, возможно, увеличит вероятность ошибки.
Вот только переменные объявляются не в контексте, где они визуально находятся, а в охватывающем контексте. Так что ошибиться легко, достаточно два раза подряд объявить одну переменную.
Так что ошибиться легко, достаточно два раза подряд объявить одну переменную.Эм-м-м… Среда разработки и компилятор вам срузу об этом скажут, в C# два раза объявить переменную в одном контексте нельзя. Или я вас неправильно понял?
Вот только они мне об этом скажут, когда я код уже скопировал и вставил. Я бы, знаете, предпочел такого избегать.
Вот только они мне об этом скажут, когда я код уже скопировал и вставил. Я бы, знаете, предпочел такого избегать.А я предпочту избежать гораздо более рутинной и неудобной реструктуризации кода при замене конструктора на метод-фабрику.
Современные IDE позволяют запросто переименовывать переменные
Это до конфликта. А после — как повезет.
а учитывая, что нацелено расширение на цепочные вызовы в expression bodied конструкциях, то вероятность возникновения коллизии имён с другими переменными минимальна.
Правда? То есть ваш прекрасный пример "а вот тут был дебаг" никому никогда не надо повторять для каждого шага в цепочке, которых бывает много?
А я предпочту избежать гораздо более рутинной и неудобной реструктуризации кода при замене конструктора на метод-фабрику.
Это той самой реструктуризации, которую современные IDE делают в один клик?
Правда? То есть ваш прекрасный пример «а вот тут был дебаг» никому никогда не надо повторять для каждого шага в цепочке, которых бывает много?Слабо понимаю вашу критику, но если вы примитивно копипастите код из одного места в другое, то конфликт имён может произойти, где угодно. Простите, но, скажу прямо, для меня такая проблема выглядит высасонной из пальца. Кроме того, вы не замечаете, как решаются конфликты другого рода, неразрешимые на текущий момент в терминах инициализационных блоков. Например,
new NamedCollection().To(out var c)
.With(c.Name = "abc")
.Merge(item1, item2, GetItem3(), item4)...И весьма интересный сценарий с замыканием графа
var tree = new Node().To(out var r).With(
r.Child = new Node().To(out var c).With(
c.Root = r
)
);Это той самой реструктуризации, которую современные IDE делают в один клик?К сожалению, IDE не может понять, когда нужен p.City?.With(...), а когда p.City = new City...
Слабо понимаю вашу критику, но если вы примитивно копипастите код из одного места в другое, то конфликт имён может произойти, где угодно.
Только не в том случае, если копируемый код представляет собой замкнутую область видимости.
Кроме того, вы не замечаете, как решаются конфликты другого рода, неразрешимые на текущий момент в терминах инициализационных блоков.
Это какие же конфликты?
new NamedCollection().To(out var c) .With(c.Name = "abc") .Merge(item1, item2, GetItem3(), item4)...
У вас у коллекции нет конструктора с множеством элементов? Сочувствую.
И весьма интересный сценарий с замыканием графа
Просто. Не. Делайте. Так. Дерево должно быть гарантированно внутренне консистентным, поэтому присвоение родителя должно автоматически добавлять элемент в коллекцию детей и наоборот.
К сожалению, IDE не может понять, когда нужен p.City?.With(...), а когда p.City = new City...
… что не имеет никакого отношения к замене конструктора на фабричный метод.
У вас у коллекции нет конструктора с множеством элементов? Сочувствую.Да? Как насчёт
ReadCollectionFromFile().To(out var c)
.With(c.Name = "abc")
.Merge(item1, item2, GetItem3(), item4)...Просто. Не. Делайте. Так. Дерево должно быть гарантированно внутренне консистентным, поэтому присвоение родителя должно автоматически добавлять элемент в коллекцию детей и наоборот.Я вам продемострровал принцип инициализации замкнутого графа, а как должно работать дерево — это уже конкретная задача, может, оно должно быть «неконсистентным» для каких-то нужд.
… что не имеет никакого отношения к замене конструктора на фабричный метод.Имеет, фабричный метод вполне может инициализировать ссылочные переменные дефолтными инстенсами, если нужно.
Person CreatePerson() => new Person {
City = new City { Name = "unknown" }
};Да? Как насчёт
Аналогично же, очевидно: new NamedCollection(ReadCollectionFromFile().Concat(...)){Name = "abc"}.
Я вам продемострровал принцип инициализации замкнутого графа, а как должно работать дерево — это уже конкретная задача, может, оно должно быть «неконсистентным» для каких-то нужд.
Так вот, я против написания кода, который позволяет делать неконсистентные структуры данных. При этом в тех редких случаях, когда циклические ссылки нужны, их просто надо описывать явно, и это прекрасно работает.
фабричный метод вполне может инициализировать ссылочные переменные дефолтными инстенсами
И что?..
Во-вторых, не знаю, как для вас, но для меня цепочные вызовы выглядят намного более структурировано и читаемо.
Так вот, я против написания кода, который позволяет делать неконсистентные структуры данных.А я не против. )
При этом в тех редких случаях, когда циклические ссылки нужны, их просто надо описывать явно, и это прекрасно работает.Вообще-то в примере они описаны явно и прекрасно работают.
Во-первых, конструктор коллекции может быть защищённым в некоторых случаях, при использовании сторонних библиотек, например.
Не повезло, сочувствую.
Во-вторых, не знаю, как для вас, но для меня цепочные вызовы выглядят намного более структурировано и читаемо.
Потому что вам нет дела до побочных эффектов.
А я не против.
Мы уже выясняли, что вы не ориентируетесь на командную работу.
Вообще-то в примере они описаны явно и прекрасно работают.
Неа. В примере введено несколько временных однобуквеных переменных, которые надо отслеживать обратно к месту создания. Явно — это вот так:
var root = new Node();
rood.AddChild(
new Node{Parent = root},
new Node{Parent = root}
);Ну и это, повторюсь, плохой пример, потому что AddChild должен сам проставлять Parent. На хорошо сделанные кольцевые ссылки можно посмотреть в примерах Sprache.
Неа. В примере введено несколько временных однобуквеных переменных, которые надо отслеживать обратно к месту создания.Для меня имя переменной не влияет на явность. Да, оно может влиять на читаемость кода, но не на явность. Если вы посмотрите декомпиляцию, то увидите, что инициализационные блоки тоже используют временные локальные переменные аналогичные To-With, разница лишь в том, что в первом случае эта переменная вводится компилятором неявно и к ней нельзя получить доступ из пользовательского кода, а во втором мы сами её явно объявляем и используем.
Для меня имя переменной не влияет на явность. Да, оно может влиять на читаемость кода, но не на явность.
Явность — это, в числе прочего, возможность проследить намерение. Если у вас намерение не видно, явности нет.
Если вы посмотрите декомпиляцию, то увидите, что инициализационные блоки тоже используют временные локальные переменные аналогичные To-With, разница лишь в том, что в первом случае эта переменная вводится компилятором неявно и к ней нельзя получить доступ из пользовательского кода, а во втором мы сами её явно объявляем и используем.
Ну так мне все равно, что там компилятор вводит, оно на читаемость моего кода не влияет.
int i = 0;
long j = i; // неявно
long k = (long) i; // явноvar p = new Person();
p.Name = "abc"; // явно
var p = new Person
{
Name = "abc"; // неявное p.Name = "abc"
}
new Person().To(out var p).With
(
p.Name = "abc"; // явно
)У вас странное определение явности в программировании, оно сильно отличается от моего.
Да, у нас вообще много взглядов на программирование различается.
var p = new Person { Name = "abc"; // неявное p.Name = "abc" }
Нет. В этом коде нет никакой неявности, интент целиком и полностью описан.
new Person().To(out var p).With ( p.Name = "abc"; // явно )
Кстати, чтобы проследить интент в этом коде, надо увидеть, где декларирована p.
Простите, а по какому определению ваш With (в отличие от immutable with) — это паттерн, и чем он более обобщенный, чем стандартное присваивание (которым и он является)?
Стоит лишь различать архитектурные паттерны (MVC, MVVM, Singleton...) и микропаттерны (ToString, TryParse, To, With...).
Поскольку снова назревает спор по терминологии, предлагаю каждому остаться при своём мнении. =)
По сути, любая обобщённая методика решения схожего рода задач является паттерном.
Я не зря привел определение в самом начале.
и микропаттерны (ToString, TryParse, To, With...).
… ничто из приведенного не является паттерном.
Согласно такому определению ToString, TryParse, To, With… являются паттернами, поскольку подразумевают некоторые закономерности при написании кода.
Согласно такому определению ToString, TryParse, To, With… являются паттернами, поскольку подразумевают некоторые закономерности при написании кода.
Согласно такому определению любая методика и спецификация в программировании является паттерном, потому что подразумевает определенные закономерности — что делает это определение бессмысленным. Поэтому нет.
И даже такие простые вещи, как способ чистки зубов, завязывания шнурков, манера говорить или выполнять либые другие регулярные действия, — зачастую обусловлены лишь поведенческими или моторными паттернами, привитыми, например, в раннем возрасте.
Что уж говорить о программировании… :)
Повторюсь, это означает, что в программировании все паттерн — и это "понятие" теряет всякий смысл.
Поэтому — нет.
Угу, давайте разберем этот смысл.
Во-первых, это высказывание говорит нам, что "все" в ООП ведет себя одинаково и обладает одинаковыми характеристиками в объеме некоего данного определения объекта. Заметим, кстати, что часто такого определения нет, и в этом случае в этом высказывании смысла нет.
Во-вторых, когда это высказывание верно, внутри ООП понятие объекта теряет смысл, потому что оно универсально (заметим, правда, что сохраняется смысл разграничивания разных объектов).
Наконец в-третьих, это высказывание позволяет отделить ООП от других парадигм программирования.
А теперь скажите мне, какой смысл в понятии "паттерн" внутри программирования, если все в программировании — паттерн?
Есть текстура, и если человек видит на ней узор (более-менее регулярную закономерность), то он вполне может сказать: «Я вижу геометрический паттерн такой-то», — и его поймут.
Паттерн предполагает закономерность. Закономерности можно искать и находить практически везде, и это очень близко к понятию пониженной энтропии. Вопрос лишь в том, насколько очевидна данная закономерность и насколько легко её выявить и проследить среди остального шума.
Так вот, код, где явно прослеживаются закономерности, с высокой степенью вероятности написан в согласии с определёнными паттернами, если же закономерности выявить затруднительно, то, возможно, его писали вразнобой.
Паттерн (информатика) — эффективный способ решения характерных задач проектирования, в частности проектирования компьютерных программ.Эффективный способ решения характерной задачи с парсингом сторок в C# — это, например, использование конструкции int.TryParse(str, out var i). Но вы, конечно, можете реализовать и свой паттерн. :)
Хотите понятную аналогию?
Нет, я хочу формальное непротиворечивое определение.
Паттерн предполагает закономерность.
Угу, вы теперь взяли и ввели еще одно определение этого понятия. И продолжает быть непонятным, каким именно вы пользуетесь (впрочем, если честно, то понятно: в каждый момент времени вы пользуетесь удобным вам).
В частности, какую дополнительную закономерность вносит "паттерн With", и чем эта закономерность отличается от любого другого использования любого другого метода?
Так вот, код, где явно прослеживаются закономерности, с высокой степенью вероятности написан в согласии с определёнными паттернами
У вас получилось рекуррентное определение: паттерн — это закономерность, которую мы проследили, потому что использовался паттерн. Бессмысленно.
если же закономерности выявить затруднительно, то, возможно, его писали вразнобой.
… а это противоречит ранее озвученному условию "в программировании все паттерн". И как так вышло?
Паттернном можно назвать как и сам белый шум, так и определённый закономерный сигнал, выделяемый из зашумленного канала в зависимоти от контекста использования и задачи.
Что касается паттернов в программировании, то их можно разделить по уровням абстракции. Сначала идут базовые паттерны самих языков программирования — это основные языковые конструкции, например, типы, циклы, условные выражения… Ведь что-то же отличает язык прораммирования от естественного человечкого языка, не так ли? Далее чуть более общее паттерны ToString, GetType, TryParse… Потом ещё более абстактные билдер, синглтон, фабрика… И в завершение, архитектурные — MVC, MVP, MVVM…
Вы, конечно, можете спорить со мной, переубеждать, но мне прекрасно живётся и с таким опредлением. Если оно вам не нравится, то продолжайте пользоваться своим, я даже не говорю, что оно в чём-то неправильное. Просто оно ваше — и это нормально разным людям иметь отличающиеся взгляды на какую-то тему.
поэтому я предпочитаю пользоваться вероятностными определениями
Да вы никаких определений не приводите, даже вероятностных.
Паттернном можно назвать как и сам белый шум,
Ну то есть когда вы говорите "паттерн With" — это то же самое, что "белый шум With", так?
Что касается паттернов в программировании, то их можно разделить по уровням абстракции. Сначала идут базовые паттерны самих языков программирования — это основные языковые конструкции, например, типы, циклы, условные выражения… Ведь что-то же отличает язык прораммирования от естественного человечкого языка, не так ли?
… но почему вы решили, что это "что-то" — это паттерны?
Далее чуть более общее паттерны ToString, GetType, TryParse…
Я ни разу не слышал, чтобы кто-то (кроме вас) называл GetString или TryParse паттерном.
Вы, конечно, можете спорить со мной, переубеждать, но мне прекрасно живётся и с таким опредлением.
Ну, если вам все равно, понимают ли вас другие люди, то можете использовать любые определения, какие вам нравится.
Просто, знаете ли, смысл определений (и, кстати, паттернов как языка) — ровно в обратном.
Я ни разу не слышал, чтобы кто-то (кроме вас) называл GetString или TryParse паттерном.Всё бывает впервые. Теперь вы услышали.
Ну, если вам все равно, понимают ли вас другие люди, то можете использовать любые определения, какие вам нравится.Пускай и приблизительно, но, думаю, вы поняли мою позицию, а я вашу — они у нас разные, и это хорошо.
Теперь вы услышали.
Нет, критерий "кроме вас" так и не выполнен.
Пускай и приблизительно, но, думаю, вы поняли мою позицию, а я вашу
Я боюсь, что то, как я понял вашу позицию, вам не понравится.
Сначала надо понять «зачем», а потом искать подходящий инструмент для решения.
Мне кажется, что предложенный вами паттерн к инициализацонным блокам вообще ортогонален, то есть ни определять его через инициализацонный блок, ни противопоставлять ему не стоит.
Звучит как «микроскоп более обобщенный, им можно не только гвозди забивать».
Сначала надо понять «зачем», а потом искать подходящий инструмент для решения.
Правостороннее присваивание и другие необычные приёмы программирования в C#