Как стать автором
Обновить
0
0
Алексей Кузнецов @NoofSaeidh

Разработчик

Отправить сообщение

Вообще private virtual вполне себе полезный кейс. Несколько раз натыкался когда он очень подходил, если бы был.

Это бывает нужно в классе в котором наследник объявляен как nested class и метод не хочется открывать на публику, но при этом надо в этом наследнике переопределить.

Воркэраунд - private protected virtual, но с тем же успехом можно сказать - зачем private, делай все internal.

Было бы интересно еще сравнить с новым FrozenDictionary (который правда пока только в превью .NET 8). Но там только GetValue / TryGetValue, без модификации словаря.

Если случаи многопоточного чтения редки, то обычного lock хватит. Если нет, можно использовать ReaderWriterLockSlim, но он может и для чтения замедлить производительность по сравнению с обычным локом, так что надо использовать осторожно. В большинстве случаев ConcurrectDictionary хватит.

Индекс - это структура, так что аллокаций нет.

Плюс, действительно, compile-time разверта есть, и более того, она работает для array-like типов которые имеют индексер и свойство Length или Count. То есть еще один duck typing. Странно, что это не отраженно в статье. Потому что, например, List<> не имеет индексер с типом Index.

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

new Person().With(name: "John", friends: new List<Person>(..))

«Добавление методов к перечислениям»
Можно пожалуйста не надо, особенно если это ваше перечисление. Лучше написать класс / структуру с нормальными методами без публичного конструктора и несколькими статическими риоднли членами из этого типа. Работает все точно так же как перечисление но без попыток натянуть сову на глобус.
Ну и вообще если вам надо добавить какую либо логику в само перечисление, значит вы делаете что-то не так.
Можно еще harmony использовать (он хотя бы не изменяет il code), но это все равно не то, что хочется делать в тестах.
«Очень легко забыть добавить в компонент destroy$, а также забыть вызвать next и complete в хуке жизненного цикла ngOnDestroy»

Не совсем понятно зачем создавать лишний объект, если метод subscribe() возвращает Unsubscribable объект с методом unsubscribe(), который делает ровно то же самое, при чем это является предпочтительным способом.
(Но ngOnDestroy все равно надо не забыть добавить вместе с вызовом unsubscribe).
Кстати можно несколько подписок в один Unsubscribable оформить вызывая метод add() subscribe1().add(subscribe2).add(subscribe3)
что бы потом все их освободить одним вызовом unsubscribe().
Я бы ещё добавил (уточнил) что в интерфейсах теперь можно писать вложенные классы, в том числе другие интерфейсы.
Из за отсутствия такой возможности ранее и, как раз таки, избегания добавления новых членов в интерфейсы, в дотнете ICollection и IReadonlyCollection не совместимы (потому что IReadonlyCollection появился позже).
Это очень удобно например для IEnumerable (что они правда пока что не сделали)
Потому что в 99.99% случаях при имплементации IEnumerable приходится писать два GetEnumerator, сейчас же можно сделать реализовать не обобщенный интерфейс в обобщенном.
И ещё очень надеюсь что наконец то ICollection станет реализовывать IReadonlyCollection. (Это брейкинг ченж без дефолтных имплементаций). Лишь бы они на это не забили.
так как это экспршн, то можно сделать кастомный статический класс со всеми необходимыми функциями.
ну а упрощать он не умеет конечно ибо обычно это просто вызов функции, например: System.Math.Sqrt(a). можно по имени функции вообще парсить и вручную оптимизировать и не вызывать системные функции.
Dispose ничего общего с GC в общем случае не имеет, и в большинстве не системных классах используется для иных целей.
Dispose используют для очистки ресурсов только когда надо освобождать неуправляему память, например при работе напрямую с DLL.
Но в реальности (продакшене) это используется как обычный метод который будет вызываться в using, с помощью него можно писать, например, структурные логи.
using(Log.Header())
using(Log.Body())
Для managed ресурсов явное написание Dispose вообще не имеет смысла.
А как это мешает? У нас раньше все только в студии сидели, но потом написали нормальные билд скрипты и некоторые пересели на райдер, а кто-то и на вс код, хотя у нас есть и старые проекты, которые только 15 студией можно открыть.
Так что тут не очень то и много зависимостей чисто на студию, особенно при переходе на райдер.
Это как с поддержкой юникода в консоли — поддержка есть, рендера нет (с недавних пор).
Так что написать можно, но только как библиотеку — что бы запустить, нужен проект на .net core или framework.
В общем немного странное утверждение конечно.
чекаут файлов тогда уж :)
Странно что никто не вспомнил про -Exclude:
ls *.log -Exclude 'result.log' | cat > 'result.log'

полная версия:
Get-ChildItem -Filter *.log -Exclude 'result.log'| Get-Content | Out-File result.log
ref struct не может быть упакована только с точки зрения языка. MSIL ничего о ref struct не знает. Кстати упаковать ref struct не так уж сложно с помощью активатора, если очень хочется.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность