Непонимаю, какие вы тут события нашли... Вообщем можете открыть статью на англ/русской википедии про IoC, там неплохо написано про то, чем это является.
Как по мне такое должно называться DI-контейнеры (так в большинстве случаев и называют). IoC это вообще про другое, это про инверсию контроля/управления. Вот когда вы в каком-нибудь любимом веб-фреймворке добавляете хэндлеры для обработки HTTP запросов, добавляете какие-нибудь middleware и потом фреймворк это вызывает, вот это и называется IoC, т.е. поток управления инвертирован, не вы вызываете, а вас вызывают.
Где оно тут сломано? IReadOnlyList - интерфейс List - класс Где тут какой дочерний интерфейс. Вот такой же пример на Java. Там получается тоже сломано?
import java.util.ArrayList;
import java.lang.Iterable;
import java.util.List;
public class Main {
public static void main(String[] args) {
// Creating and initializing an ArrayList
ArrayList<Integer> originalList = new ArrayList<>(List.of(1, 2, 3, 4));
Iterable<Integer> list = originalList;
// Error
// list.add(5);
// However, we can cast back to ArrayList and modify the original list
((ArrayList<Integer>) list).add(5);
// Output: 5
System.out.println(originalList.size());
}
}
Вас только mono смутило?) А использование HttpListener вместо ASP.NET Core? А использование напрямую mono компилятора с указанием конкретного файла для компиляции? А подключение библиотек, через ручное скачивании dll и указанием их через -r параметр? Это не пример, это анти-пример.
А знаете какие-нибудь решения для миграции в БД, которые можно к Юнити подключить. Мне в голову только EF/EF Core приходит, но его вряд ли получиться к Юнити подключить, хотя попробовать можно :)
Ох, как мне это нравится). Пришли иксперды и начали рассказывать про DCL, volatile, memory barrier (хотя в рамках .NET рантайма тот код полностью валиден и не надо там никакого volatile, вот пример от самих MS - https://github.com/dotnet/runtime/blob/main/docs/design/specs/Memory-model.md#examples-and-common-patterns), но при этом главную проблему не заметили: Random сам по себе не thread-safe и нельзя вызывать Next из нескольких потоков. В .NET довольно давно уже есть thread-static переменная Random.Shared, которую и рекомендуется использовать.
Навороты конечно непростые, но про оверхед вы не правы. Эти "аппендеры" являются структурами нулевого размера, которые используются как типы-параметры в дженерик методе, тут нет никаких аллокаций и кастов и, скорее всего, весь код "аппендеров" будет заинлайнен JIT'ом.
В .NET 7 завесли новый GC основанный на сегментах и регионах. Возможно это влиет на стратегию возврата памяти OC. В этой статье рассказано как происходит decommit памяти в новом GC
Непонимаю, какие вы тут события нашли... Вообщем можете открыть статью на англ/русской википедии про IoC, там неплохо написано про то, чем это является.
Как по мне такое должно называться DI-контейнеры (так в большинстве случаев и называют). IoC это вообще про другое, это про инверсию контроля/управления. Вот когда вы в каком-нибудь любимом веб-фреймворке добавляете хэндлеры для обработки HTTP запросов, добавляете какие-нибудь middleware и потом фреймворк это вызывает, вот это и называется IoC, т.е. поток управления инвертирован, не вы вызываете, а вас вызывают.
Ну быстрое гугление говорит, что это DI библиотеки для Go. При чем тут это?
IoC не имеет отношения к DI, держу в курсе.
Где оно тут сломано?
IReadOnlyList - интерфейс
List - класс
Где тут какой дочерний интерфейс. Вот такой же пример на Java. Там получается тоже сломано?
Я так понимаю, сделать:
dotnet new console -o Test
cd ./Test
dotnet run
Не позволила религия и пришлось писать сей огромный скрипт?
Немного не понял про рантайм, все современные GC спокойно работают с цикл. ссылками и чистят память правильно.
Это в любом случае будет null. ? оператор не дает вызвать метод, если ссылка null, без разницы, это extension метод или метод класса.
Вас только mono смутило?) А использование HttpListener вместо ASP.NET Core? А использование напрямую mono компилятора с указанием конкретного файла для компиляции? А подключение библиотек, через ручное скачивании dll и указанием их через -r параметр? Это не пример, это анти-пример.
В репе .NET есть дизайн док на эту тему, но когда это будет реализовано неизвестно.
А знаете какие-нибудь решения для миграции в БД, которые можно к Юнити подключить. Мне в голову только EF/EF Core приходит, но его вряд ли получиться к Юнити подключить, хотя попробовать можно :)
Окей, я просто ориентировался на тот кусочек кода, который был в комментарии, тогда я вообще никаких проблем не вижу.
Ох, как мне это нравится). Пришли иксперды и начали рассказывать про DCL, volatile, memory barrier (хотя в рамках .NET рантайма тот код полностью валиден и не надо там никакого volatile, вот пример от самих MS - https://github.com/dotnet/runtime/blob/main/docs/design/specs/Memory-model.md#examples-and-common-patterns), но при этом главную проблему не заметили: Random сам по себе не thread-safe и нельзя вызывать Next из нескольких потоков. В .NET довольно давно уже есть thread-static переменная Random.Shared, которую и рекомендуется использовать.
Навороты конечно непростые, но про оверхед вы не правы. Эти "аппендеры" являются структурами нулевого размера, которые используются как типы-параметры в дженерик методе, тут нет никаких аллокаций и кастов и, скорее всего, весь код "аппендеров" будет заинлайнен JIT'ом.
А может все-таки лучше возврашать обычный инстанс структуры, чтобы вызывающий код сам решал, нужен Rc, Arc или вообще ничего.
В .NET 7 завесли новый GC основанный на сегментах и регионах. Возможно это влиет на стратегию возврата памяти OC. В этой статье рассказано как происходит decommit памяти в новом GC
А вообще, по моему мнению, за крутыми enum нужно идти в rust. Я хоть и шарпист, но мне очень нравится как enum в rust реализованы.