Makeman

В статье рассмотрен аналогичный сценарий — пару раз встретишь на практике, научишься и путаница исчезнет.

Ошибки загрузки из файла обрабатываются в самих дочерних вью-моделях.

На момет окончания метода 'CoreViewModel.Expose' важно выполнить лишь Expose у коллекции документов, а загрузкой данных из файла заведует сам документ.

Как говорится: «Любое категоричное суждение ошибочно, даже это». Поэтому не стоит воспринимать мои слова как абсолютную истину :)

Здорово, что вы критикуете и обдумываете аргументы, не принимая их сразу на веру, ведь я тоже могу ошибаться, заблуждаться и быть слишком субъективным.

Знаете, за немало лет коммерческого программирования мне трудно вспомнить даже пару случаев, когда бы я имел дело с сотнями тысяч и уж тем более с миллионами объектов. Разве что в тестовых целях проверял производительность каких-то методов на больших массивах.

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

Здесь разное поведение.

Думаю, так будет лучше видна разница в логике

Documents.CollectionChangeCompleted += (sender, args)
{
    var document = args.NewItems?
        .Cast<ADocument>().LastOrDefault();
    if (document != null) ActiveDocument = document;
}

По задумке не нужно менять активный документ, если, например, пользователь закрыл другой неактивный и сработало событие 'CollectionChangeCompleted'.

Без ожидания параллельно.

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

Поэтому для себя не вижу существенных причин отказываться от 'With'.

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

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

В любом случае, иногда полезно взглянуть даже на хорошо знакомые вещи с другой стороны. Своего рода разминка для ума. :)

По многим пунктам с вами согласен.

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

Что касается синтаксической части библиотеки — это во многом исследовательская работа, способ взглянуть на язык с нового ракурса, поиск путей развития.

Возможно, есть люди, которым такое тоже интересно, а статья послужит поводом для переосмысления даже таких фундаментальных вещей, как присваивание и передача параметров в методы.

Смотрите сами, что вам больше по душе. ))

Всё просто — в первом цикле инициализируем вью-модели документов, а во втором асинхронно загружаем в каждую информацию из файлов.

Если вы хотите подковырнуть меня тем, что я дважды прохожусь по коллекции, то здесь это никаких проблем не вызывает.

Можете даже скомпилировать проект и убедиться, что всё работает вполне себе живо. :)

Скорее: «Смотри, ты тоже так можешь!»

Как уже говорил ранее, мне близок дух изобретательства и свободы в программировании. Но каждому человеку своё — кому-то больше по душе традиционные подходы.

Но я думаю, что есть и такие люди, которым интересен новаторский взгляд в программировании, а эта статья поможет им взглянуть на знакомые вещи с другого ракурса…

Предлагаю вам самим сделать бенчмарк по вашим канонам и сравнить с результатами, полученными мной. Возможно, моя методика не так уж точна, но порядок величин, думаю, вполне ясен. Хотите опровергнуть — за дело!

Буду рад распрощаться со своими заблуждениями насчёт вызова пустых методов.

Если для вас это выглядит «хламом», то не пользуйтесь. )

Насчёт совмещения — это демонстрационный пример, задача которого показать различные сценарии использования. Конечно, я бы мог разбить его на более мелкие части, но в собранном виде мне нравится больше.

По ссылке можно увидеть пример стиля, в котором я предпочитаю писать код.

Вы пробовали когда-нибудь замерить, скольколько же стоит вызов пустого метода?

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', вызов этот занимает порядка одной стомиллионной секунды на среднем компьютере. Уверен, что даже для мобильных устройств эта цифра будет вполне адекватная.

Скажу так… насчёт expression-bodied стиля:

• провоцирует оформлять код мелкими методами с раздельной отвественностью
• меньше скобок и лишних слов вроде return
• эстетически красиво и лаконично
• развивает чувство прекрасного
• учит писать чистый и общённый код

И лично для меня последние пункты самые важные. :)
Если бы не эта математическая красота, то давно бы уже забросил программирование!

Что вы подразумеваете под сбросом состояния? Насколько я понимаю, локальные переменные всегда остаются в стеке (во многом это и вызывает stack overflow при крайне глубоком рекурсивном вызове методов). Зачем их куда-то ещё сбрасывать, чтобы потом восстанавливать?

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

Моё понимание интуитивно, поэтому могу ошибаться, поправьте, если что не так. :)

Можете рассмотреть и такой сценарий, где применение метода-расширения более оптимально, чем родного PM, имплементация которого содержит подводный камень в виде упаковок для типов-значений, а также работает лишь с константными выражениями.

referencesource.microsoft.com/#mscorlib/system/collections/generic/equalitycomparer.cs

… в то время, как для большей части (а в моей личной практике — для всех) случаев достаточно использовать оператор is. Ну да, ну да.

Как же вы отличаете те случаи, где можно было бы ещё применить оператор 'is', если даже не знаете про какие конкретно обобщения я говорю?

Коечно, до того, как ввели, например, pattern-matching, большинству разработчиков хватало и базовых возможностей 'is'.

Ну, во-первых, никаких десятистраничных пояснений тут нет. :)

Да, подход новый и непривычный, но после десяти минут внимательного и вдумчивого изучения всё становится на свои места и в дальнейшем не вызывает трудностей.

Конечно, это ваше дело, использовать или нет подобные решения. Всего лишь делюсь личным опытом с другими людьми. Каждый сам решит, насколько ему это пригодно.

Хороший вопрос.

Правое присваивание очень уместно в таких случаях:
— expression-bodied методах
— при деконструкции объектов
— в цепочных вызовах

Левое присваивание на данный момент больше подходит для:
— арифметических выражений
— при присваивании свойств (к ним нельзя применить правое присваивание в текущей реализации, хотя если бы существовал на уровне языка оператор 'to', то можно было бы применять и для них)

В остальных случаях ориентируюсь по контексту, где что лучше смотреться будет.

Многое в C# можно переписать без дополнительного синтаксического сахара: автоматические свойства, создание делеготов, лямбда-выражения… те же инициализационные блоки, например,

var p = new Person();
p.FirstName = "Иван";
p.LastName = "Пупкин";

var p = new Person
{
    FirstName = "Иван",
    LastName = "Пупкин"
}

Может, это и не самая остро необходимая функция языка, но мне она весьма по душе. :)

На самом деле C# довольно хороший и продуманный язык. Да и это всего лишь инструмент, а как его использовать, решать самому разработчику. Ведь если язык позволяет вытворять такие вещи, что описаны в публикации, то почему бы и нет? )

Ко мнениям окружающих я прислушиваюсь и при достаточной аргументации готов даже поменять своё личное.

К сожалению, убедительных аргументов в пользу того, что 'is var' и 'case var' для чего-то должны возвращать всегда только 'true' мне найти не удалось, хотя обратных доводов могу привести немало.

Вовсе не утверждаю, что теперь нужно вносить breaking changes, меня больше интересует, как мог бы выглядеть язык в идеальном случае. Ну, и то, что можно теперь использовать методы расширения 'Is' с чистой и предсказуемой имплементацией в случае необходимости. Кстати, для подхода с методом 'Is' можно также получить ряд любопытных обобщений, которых нет сейчас в языке.

У такого подхода есть ряд недостатков:

— нельзя без замыканий выводить значения в новые переменные (производить деконструкцию объекта)

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); // получим исходное значение вместо "Иван" 

— больше скобок и меньше похоже на инициализационные блоки

Хотя, конечно, никто не отменяет и этот подход, кому что ближе. :)

Ссылка для информации и просто для тех людей, кому интересна тема.

Выгляди так, словно ваша самоцель — обсуждения на хабре. Моя цель — поиск истины, математической красоты и рабочих решений, а обсуждения — только малая часть этого пути.

По правде говоря, я уже устал обсуждать эту тему, поскольку обсуждалась она не только тут. В английском варианте собраны финальные аргументы, и люди, которые приложили некоторые усилия, смогли уловить их смысл.

Замечательно! Рад за вас! )

Присмотритесь повнимательнее, вникните. Утверждения вовсе не случайны.

Если же вы не улавливаете взаимосвязи, то, к сожалению, ничем не могу помочь.

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

Подробный разбор на английском языке

bitbucket.org/Makeloft/ace/issues/1/research-of-pattern-matching

CC: lair PsyHaSTe orthoxerox

Хорошо понимаю, что на первый взгляд все эти конструкции выглядят жутко непривычно, но когда к ним привыкаешь, то постепенно начинаешь видеть их красоту. К тому же никто не призывает использовать сложные рекурсивные выражения, можно ограничиться простыми и понятными, например,

var (x, y, z) = 1;

Ну, это только чать айзберга. :)

Граница есть, но лишь условная, поэтому вы можете её свободно пересекать в любую сторону — в этом своя прелесть!

Этот подход плохо применим в командной работе.

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

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

Что вас смущает? ) Переменные в стеке? Это не работа с кучей, здесь ощутимого падения производительности не происходит.

Вообще-то в нашем случае 'with' выражает пусть и видимую, но вполне осязаемую структуру кода.

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

Теперь у нас есть конструктор или лего, из которых можно собрать множество вариаций автомобилей и не только, даже самых нелепых и абсурдных! Огромный простор для фантазии!

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

Да, контекст не влияет на поведение 'with' и аргументы. Здесь ответственность программиста и полная свобода действий.

Лично для меня близка свобода в программировании, делай, как тебе нравится, а если что-то работает не так, то сам виноват. Меньше ограничений — больше возможностей.

Монады не позволяют совершать деконструкцию объекта и объявлять новые переменные для дальнейшего использования в вызывающем методе.

Ваш выбор и ваше дело.

Для меня видимость структуризации, читаемость и выразительность — очень близкие в данном случае понятия.

Но особенно меня цепляет глобальная симметричность и математическая красота подхода в плане обобщений. Это трудно объяснить и сразу прочувствовать, но мне самому теперь нравится, хотя поначалу были сомнения в его целесообразности.

Спасибо, буду называть правильно.

С точки зрения метода 'With' есть контекст, который будет обратно возвращён в цепочку вызовов.

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