Знаете, за немало лет коммерческого программирования мне трудно вспомнить даже пару случаев, когда бы я имел дело с сотнями тысяч и уж тем более с миллионами объектов. Разве что в тестовых целях проверял производительность каких-то методов на больших массивах.
Обычно в таких сценариях, где много данных и важна высокая скороть их обработки, уже пишут код на более низкоуровневых языках.
Спасибо! Но когда речь идёт о стомиллионных долях секунды, то разница в пять и даже сто раз просто не ощутима на практике, за исключением очень редких случаев, где важна производительность или очень много данных.
Поэтому для себя не вижу существенных причин отказываться от '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', вызов этот занимает порядка одной стомиллионной секунды на среднем компьютере. Уверен, что даже для мобильных устройств эта цифра будет вполне адекватная.
• провоцирует оформлять код мелкими методами с раздельной отвественностью
• меньше скобок и лишних слов вроде return
• эстетически красиво и лаконично
• развивает чувство прекрасного
• учит писать чистый и общённый код
И лично для меня последние пункты самые важные. :)
Если бы не эта математическая красота, то давно бы уже забросил программирование!
Что вы подразумеваете под сбросом состояния? Насколько я понимаю, локальные переменные всегда остаются в стеке (во многом это и вызывает stack overflow при крайне глубоком рекурсивном вызове методов). Зачем их куда-то ещё сбрасывать, чтобы потом восстанавливать?
Думаю, что современные языки отлично оптимизированы для работы со стеком вызовов и поощеряют разделение кода на маленькие методы.
Моё понимание интуитивно, поэтому могу ошибаться, поправьте, если что не так. :)
Можете рассмотреть и такой сценарий, где применение метода-расширения более оптимально, чем родного PM, имплементация которого содержит подводный камень в виде упаковок для типов-значений, а также работает лишь с константными выражениями.
Ну, во-первых, никаких десятистраничных пояснений тут нет. :)
Да, подход новый и непривычный, но после десяти минут внимательного и вдумчивого изучения всё становится на свои места и в дальнейшем не вызывает трудностей.
Конечно, это ваше дело, использовать или нет подобные решения. Всего лишь делюсь личным опытом с другими людьми. Каждый сам решит, насколько ему это пригодно.
Правое присваивание очень уместно в таких случаях:
— expression-bodied методах
— при деконструкции объектов
— в цепочных вызовах
Левое присваивание на данный момент больше подходит для:
— арифметических выражений
— при присваивании свойств (к ним нельзя применить правое присваивание в текущей реализации, хотя если бы существовал на уровне языка оператор 'to', то можно было бы применять и для них)
В остальных случаях ориентируюсь по контексту, где что лучше смотреться будет.
Многое в C# можно переписать без дополнительного синтаксического сахара: автоматические свойства, создание делеготов, лямбда-выражения… те же инициализационные блоки, например,
var p = new Person();
p.FirstName = "Иван";
p.LastName = "Пупкин";
var p = new Person
{
FirstName = "Иван",
LastName = "Пупкин"
}
Может, это и не самая остро необходимая функция языка, но мне она весьма по душе. :)
На самом деле C# довольно хороший и продуманный язык. Да и это всего лишь инструмент, а как его использовать, решать самому разработчику. Ведь если язык позволяет вытворять такие вещи, что описаны в публикации, то почему бы и нет? )
Обычно в таких сценариях, где много данных и важна высокая скороть их обработки, уже пишут код на более низкоуровневых языках.
Думаю, так будет лучше видна разница в логике
По задумке не нужно менять активный документ, если, например, пользователь закрыл другой неактивный и сработало событие 'CollectionChangeCompleted'.
Поэтому для себя не вижу существенных причин отказываться от 'With'.
Может быть, кто-то захочит покрутить их в свои личных проектах, а кто-то внедрит и в коммерческий. В публикации я никого не призываю делать их мейнстримом, только лишь делюсь личным опытом и наработками.
В любом случае, иногда полезно взглянуть даже на хорошо знакомые вещи с другой стороны. Своего рода разминка для ума. :)
Проект Ace — это набор базовых библиотек, которые я использую в качестве основы для других своих проектов. Своего рода экстракт моих наработок и знаний за годы активного программирования.
Что касается синтаксической части библиотеки — это во многом исследовательская работа, способ взглянуть на язык с нового ракурса, поиск путей развития.
Возможно, есть люди, которым такое тоже интересно, а статья послужит поводом для переосмысления даже таких фундаментальных вещей, как присваивание и передача параметров в методы.
Если вы хотите подковырнуть меня тем, что я дважды прохожусь по коллекции, то здесь это никаких проблем не вызывает.
Можете даже скомпилировать проект и убедиться, что всё работает вполне себе живо. :)
Как уже говорил ранее, мне близок дух изобретательства и свободы в программировании. Но каждому человеку своё — кому-то больше по душе традиционные подходы.
Но я думаю, что есть и такие люди, которым интересен новаторский взгляд в программировании, а эта статья поможет им взглянуть на знакомые вещи с другого ракурса…
Буду рад распрощаться со своими заблуждениями насчёт вызова пустых методов.
Насчёт совмещения — это демонстрационный пример, задача которого показать различные сценарии использования. Конечно, я бы мог разбить его на более мелкие части, но в собранном виде мне нравится больше.
По ссылке можно увидеть пример стиля, в котором я предпочитаю писать код.
На моём не самом передовом компьютере 100 000 000 вызовов заняли около секунды на релизном билде. То есть вызов 'With' занимает 1/100 000 000 (одну стомиллионную секунды)!
Не знаю, как вам, но для моих задач этого хватит с лихвой.
Конечно, в редчайших случаях, где важна сверхпроизводительность, инлайнинг, наверняка, помогает, но это уже другая область в разработке.
Так что не стоит сгущать краски над 'With', вызов этот занимает порядка одной стомиллионной секунды на среднем компьютере. Уверен, что даже для мобильных устройств эта цифра будет вполне адекватная.
• провоцирует оформлять код мелкими методами с раздельной отвественностью
• меньше скобок и лишних слов вроде return
• эстетически красиво и лаконично
• развивает чувство прекрасного
• учит писать чистый и общённый код
И лично для меня последние пункты самые важные. :)
Если бы не эта математическая красота, то давно бы уже забросил программирование!
Думаю, что современные языки отлично оптимизированы для работы со стеком вызовов и поощеряют разделение кода на маленькие методы.
Моё понимание интуитивно, поэтому могу ошибаться, поправьте, если что не так. :)
referencesource.microsoft.com/#mscorlib/system/collections/generic/equalitycomparer.cs
Как же вы отличаете те случаи, где можно было бы ещё применить оператор 'is', если даже не знаете про какие конкретно обобщения я говорю?
Коечно, до того, как ввели, например, pattern-matching, большинству разработчиков хватало и базовых возможностей 'is'.
Да, подход новый и непривычный, но после десяти минут внимательного и вдумчивого изучения всё становится на свои места и в дальнейшем не вызывает трудностей.
Конечно, это ваше дело, использовать или нет подобные решения. Всего лишь делюсь личным опытом с другими людьми. Каждый сам решит, насколько ему это пригодно.
Правое присваивание очень уместно в таких случаях:
— expression-bodied методах
— при деконструкции объектов
— в цепочных вызовах
Левое присваивание на данный момент больше подходит для:
— арифметических выражений
— при присваивании свойств (к ним нельзя применить правое присваивание в текущей реализации, хотя если бы существовал на уровне языка оператор 'to', то можно было бы применять и для них)
В остальных случаях ориентируюсь по контексту, где что лучше смотреться будет.
Может, это и не самая остро необходимая функция языка, но мне она весьма по душе. :)