Комментарии 19
Интересный проект, но использовать его я конечно не буду :)
Ничего личного, считаю что явное - лучше неявного, особенно в таких местах как многопоточный код под высокой нагрузкой. Лучше потрачу немножко времени и сделаю ровно то, что нужно мне - ни больше ни меньше, со всякой валидацией, логгированием ровно в тех местах, где мне необходимо.
Для прототипирования и/или как кристаллизация устоявшихся подходов в ваших проектах в отдельный нугет - очень даже неплохо, уверен, что найдёт своё применение. Поставил звезду на гитхабе :)
Удалено
А почему параметр не передаётся как in? JIT-компилятор не настолько умный, и каждая передача структуры будет сопровождаться её копированием.
Ну и преимущество оператора with: можно менять сразу несколько полей за раз.
А почему параметр не передаётся как
in? JIT-компилятор не настолько умный, и каждая передача структуры будет сопровождаться её копированием.
Спасибо за идею, добавлю в ближайшее время, и напишу бенчмарки
Ну и преимущество оператора
with: можно менять сразу несколько полей за раз.
Согласен
С версии 1.0.3 для C# 7.2+ для struct и record struct используется модификатор параметра in
Ну и преимущество оператора
with: можно менять сразу несколько полей за раз.
Да вот ещё подумал, что ни что не мешает использовать with вместе с Immutype
Код от этих нововведений читабильнее не стал. Если вам понадобилось менять не изменяемое и это делаеться через копии объектов, то в проекте явно что-то идёт не по плану. Оптимальный код всегда в простой и доброй, старой, самой первой спецификации языка, научитесь писать на ней, никакие обёртки будут не нужны.
Код от этих нововведений читабильнее не стал.
Читабелность – это конечно же очень субъективно.
Если вам понадобилось менять не изменяемое и это делаеться через копии объектов, то в проекте явно что-то идёт не по плану.
Immutype создает методы что бы сделать модифицированные копии и ни в коем случае не пытается менять оригиналы объектов. На похожем API, например, построен Roslyn.
Оптимальный код всегда в простой и доброй, старой, самой первой спецификации языка, научитесь писать на ней, никакие обёртки будут не нужны.
Возможно, Immutype поможет сэкономит время, если человек делает подобные вещи вручную. Если не делает, то конечно же ему и не нужен Immutype. Я пытаюсь тратить побольше времени на изучение.
Вопрос: а компилятор C# (с оператором with или без него) умеет оптимизировать создание таких копий? В смысле, если оригинал больше не используется – модифицировать его и возвращать вместо копии?
Грубо говоря, в вызове new Person().WithName("John").WithAge(15) не создавать три разных объекта, а создать только один с нужными полями.
Нет, не умеет. Компилятор C# только транслирует C#-код в MSIL лишь с небольшим числом оптимизаций. Проверяется просто: через декомпиляцию. Оптимизации также может применять JIT-компилятор, но он вынужден компилировать код быстро, и потом на подобные фокусы тоже не способен.
Слишком умно для него. Скорее всего, даже старые версии .NET заинлайнят вызовы WithName и WithAge - инструкций там совсем мало и добавлен атрибут для агрессивного инлайнинга, а в .NET 6 его еще более агрессивным сделали :) Фактически останется только вызов конструкторов, а это ну оооочень быстра операция в .NET. Также можно убрать проверки аргументов для случаев, когда включена нулабилити, но они полезны, а прирост производительности будет минимальным. Я сделаю бенчмарки что бы сравнить с with. Но как я уже упомянул, ни что не мешает миксовать ключевой слово with и вызовы сгенерированных статических методов там где удобно для записей. Остальные типы можно использовать через статические методы.
Добавил еще поддержку универсальных типов со всеми возможными ограничениями параметров типа
Immutype упростит работу с неизменяемыми типами данных