Я уже повозился с атрибутами. Теперь можно вот так:
public static class UserMapper
{
[AOTMapperMethod]
public static User MapToUser(this IAOTMapper, UserEntity input)
{
var output = new User();
output.Name = input.Name;
output.Age = input.Age;
return output;
}
}
// ...
var mapper = new AOTMapperBuilder()
.AddTestProject() // magic extension method, we will talk about it later
.Build();
var entity = new UserEntity
{
Name = "John",
Age = 30
};
var user = mapper.Map<User>(entity);
Console.WriteLine(user.Name); // John
Console.WriteLine(user.Age); // 30
В придачу маппер еще следит за тем чтобы все пропертя были проинициализированы. Еще есть на чем работать, но я уже использую где нужен AOT. Немного больше readme в репозитории. https://github.com/byme8/AOTMapper
В местах не столь отдаленых, к таким "терористам" б в квартиру бы наведался спецназ со штурмом. Увез в неизвестном напралении, а потом бы "терориста" нашли с посторонными предметами в неожиданых местах.
Или зачем нужны out параметры при наличии возможности возвращать несколько значений, но out параметры появились раньше, странно было бы их удалять.
Они очень часто используются для вызова С/С++ библиотек. А это то на чем живет dotnet внутри. Плюс они уже прижились в разных API-аях те же TryParse/TryGet и т.д.
Вы можете добавить pattern-matching в switch, но не можете удалить старый switch. В лучшем случае задеприкейтеть его и удалить лет через 10.
Они все-таки не однозначны. pattern-matching switch не может заменить все старые switch.
Просто static ещё можно как-то понять и простить. Cамому иногда такого хочется в связке с дженериками. Но там всё прикольней - static abstract и static virtual в интерфейсах... это уже перебор
В оригинале: > Panasonic this year established a test line in Japan to make the 4680 format, which is a 46 mm (1.6 inches wide) and 80 mm tall battery cell that Tesla says will store more energy, halve battery costs and drive a 100-fold increase in battery production by 2030.
Я бы сказал здесь имееться ввиду что их будуть производить в 100 раз больше чем раньше. О емкости речи вобще не идет.
Если его тип известен, то рефлексия по сути дела не нужна, ибо результат (o is RequiredAttribute) известен на этапе компиляции
Он то известен, но удобного способа им воспользоваться нет. Разве что разработчик должен сам за этим следить и вовремя подправлять.
Как такое работает?
Сейчас AOT рефлексия зависит от типов над которыми происходят манипуляции, но я уже придумал как можно сделать, так чтобы она понимала, что спрятано за интерфейсом.
Думаю что намного лучше не строить АОТ рефлексию заранее
AOT рефлексия строится зарание, но не инициализируется, и только для типов для которых мы её вызываем. Сама инициализация происходит в момент первого вызова.
если быстродействия стандартной не хватает.
Этот момент не понял. Как мы можем узнать, что быстродействия не хватает на этапе компиляции? Эта информация хранится в голове разботчика и это уже его задача решать что использовать и в какой ситауции.
Например, не добавлять туда abstract вовсе. Поскольку, интерфейс сам по себе требует чтобы класс все реализовал. А то получается смесь конракта и реализации. Ещё есть вариант с Shapes. В этом случае, вводится новый способ расширать поведение классов и интерфейсов. Да, это более сложно реализовать, но они уже показывали демо с ним и расказывали что очень хотят его ввести. Наcколько я понял, Shap-ы покрывают эту фичу полностью.
Есть вариант добивить какие-то новые интерфейсы которые будут работаеть через ducktyping и уже в них воротить что угодно, поскольку они никак не связаны со старыми. Этот вариант уже чисто мои фантазии, не видел чтобы они даже обсуждали что-то подобное.
На этом мой парсер сломаслся. Мне совсем не понятна идея называть подобные методы abstract.Ну вот прям всё против этого. Во первых, это интерфейс, а не абстрактный класс. Во вторых, он СТАТИЧЕСКИЙ! Есть же много других способов, но был выбран именно этот, который вызывает дисонанс у всех подряд.
Например, когда он отвечает за много всего сразу. Любой кто захочет его реализовать сделает это по другому и очень высока вероятность что это «по другому» может что-то сломать. Именно это и происходит с IQueryable.
У меня тоже возникают подобные мысли, но я не вижу альтернативы. Да можно делать простые специализированые репозитории, но они плохо работают когда нужно сделать какой-то разухабистый фильрт с кучей условий. Не всегда понятно куда пихать всю эту логику. В DAL-е слишком низкоуревнево, в бизнес логике слишком не абстрактно.
Я уже повозился с атрибутами. Теперь можно вот так:
В придачу маппер еще следит за тем чтобы все пропертя были проинициализированы.
Еще есть на чем работать, но я уже использую где нужен AOT.
Немного больше readme в репозитории.
https://github.com/byme8/AOTMapper
Есть вот такая штука https://github.com/Cysharp/MagicOnion Работает поверх grpc, но использует интефейсы вместо proto файлов
В местах не столь отдаленых, к таким "терористам" б в квартиру бы наведался спецназ со штурмом. Увез в неизвестном напралении, а потом бы "терориста" нашли с посторонными предметами в неожиданых местах.
del
Они очень часто используются для вызова С/С++ библиотек. А это то на чем живет dotnet внутри. Плюс они уже прижились в разных API-аях те же TryParse/TryGet и т.д.
Они все-таки не однозначны. pattern-matching switch не может заменить все старые switch.
Просто static ещё можно как-то понять и простить. Cамому иногда такого хочется в связке с дженериками. Но там всё прикольней - static abstract и static virtual в интерфейсах... это уже перебор
В оригинале:
> Panasonic this year established a test line in Japan to make the 4680 format, which is a 46 mm (1.6 inches wide) and 80 mm tall battery cell that Tesla says will store more energy, halve battery costs and drive a 100-fold increase in battery production by 2030.
Я бы сказал здесь имееться ввиду что их будуть производить в 100 раз больше чем раньше. О емкости речи вобще не идет.
Это все таки другое. Оно работает в этом случаи это:
- ничего не поломано
- нет предпосылок к тому что что-то сломается
Да не понятно как это работает, но оно работает поэтому лучше не трогать
Он то известен, но удобного способа им воспользоваться нет. Разве что разработчик должен сам за этим следить и вовремя подправлять.
Сейчас AOT рефлексия зависит от типов над которыми происходят манипуляции, но я уже придумал как можно сделать, так чтобы она понимала, что спрятано за интерфейсом.
AOT рефлексия строится зарание, но не инициализируется, и только для типов для которых мы её вызываем. Сама инициализация происходит в момент первого вызова.
Этот момент не понял. Как мы можем узнать, что быстродействия не хватает на этапе компиляции? Эта информация хранится в голове разботчика и это уже его задача решать что использовать и в какой ситауции.
Упс. Мой косяк. Скопировал не из того тестового проєкта. Уже поправил.
Да. Если не брать в расчет инициализацию должно быть быстро, но в теории могут быть проблемы с AOT компиляцией. Я ещё буду смотреть что и как там.
Добавил примеры.
Например, не добавлять туда abstract вовсе. Поскольку, интерфейс сам по себе требует чтобы класс все реализовал. А то получается смесь конракта и реализации.
Ещё есть вариант с Shapes. В этом случае, вводится новый способ расширать поведение классов и интерфейсов. Да, это более сложно реализовать, но они уже показывали демо с ним и расказывали что очень хотят его ввести. Наcколько я понял, Shap-ы покрывают эту фичу полностью.
Есть вариант добивить какие-то новые интерфейсы которые будут работаеть через ducktyping и уже в них воротить что угодно, поскольку они никак не связаны со старыми. Этот вариант уже чисто мои фантазии, не видел чтобы они даже обсуждали что-то подобное.
На этом мой парсер сломаслся. Мне совсем не понятна идея называть подобные методы
abstract.Ну вот прям всё против этого. Во первых, это интерфейс, а не абстрактный класс. Во вторых, он СТАТИЧЕСКИЙ! Есть же много других способов, но был выбран именно этот, который вызывает дисонанс у всех подряд.Я правильно понимаю, что хабр превращается в политический филиал "единой россии"? На днях была статья о боге, теперь это...