Pull to refresh
32
0
Dmitry Tikhonov @0x1000000

Software Developer

Send message
Для программы на QT все равно придется делать отдельную Web версию (если такая требуется), а c Электроном получаем все платформы “одним махом”.

Вы утирируете. Здесь имелись в виду основные принципы работы, которые senior знать должен.

async/await, безусловно, имеет свою цену, но применяется он в 90% случаев для операций ввода-вывода (например, запрос к БД) длительность которых, как правило, на порядки превышает все возможные задержки вызванные созданием/удалением дополнительных объектов необходимых для async/await, но при этом выигрыш в производительности от того, что мы можем обойтись меньшим количеством потоков для обработки большого количества входящих запросов и легкость с которой можно этого достичь говорит, что: “всегда используйте async/await (для ввода/вывода), и не заморачивайтесь”. Если, таки, хочется “пооптимизировать” рассмотрите новый ValueTask (которого еще не было во времена написания оригинала этой статьи)

Главная проблема ORM это непредсказуемость и как результат — вероятные проблемы с производительностью, но это плата за удобство. Вопрос в том в том, что важнее в каждом конкретном случае.

Вообще-то, нормальные ORM транслируют "where" "order by" (и пр.) в SQL код, так что фильтрацию и сортировку делает база.

Описанные вами удобства относятся к "Query Builder", который может применятся отдельно от ORM.

Thank you for the link — it just one more time proves the rule: «If you think you invented something new then someone certainly invented that before». But at least my version has some improvements — you can choose which task should be run in parallel and which sequentially, so you can convert «Improper monad» (term from the article ) to «Proper monad» at the moment you need them
Я понимаю, что это материал для новичков, но все же стоило бы ответить на вопрос из самой первой картинки, либо не вставлять ее в текст совсем. А то получается, что ружье, висящее на стене, так и не выстрелило (себе в ногу).
Вообще согласен — такого действительно нет. Хаскель, кстати, тоже ошибку кидает Non-exhaustive patterns in case.

И в принципе понятно почему нет, если мы перебрали все возможные варианты (например, bool: true|false), то дефолтная ветка не нужна, соответственно нельзя ее сделать обязательной на уровне языка.

Но это проблему можно (и на мой взгляд нужно) решить через предупреждение компилятора.
По поводу Int32 и Double — это честное неявное приведение типов, которое не зависит от каких-либо предварительных проверок.

Я такое приведение могу сделать и для других типов определяя оператор «implicit».

А что рефлекшн говорит по поводу «string?»?

Ответ в статье:
Теперь самый важный вопрос: что же поменялось в IL? С точки зрения исполняемого кода — ничего!
Если бы «string?» был другим типом, то требовалось бы приведение типов, но код ниже будет скомпилирован без предупреждений:

string notNullable = "value1";
string? nullable = "value2";
if(nullable != null)
{
      notNullable = nullable;
}


но зато:

int? nullable = 1;
int notNullable = 2;

if (nullable != null)
{
    notNullable = nullable;
}


выдаст ошибку:
error CS0266: Cannot implicitly convert type 'int?' to 'int'. An explicit conversion exists (are you missing a cast?)
второму нельзя присвоить null

Очень даже можно, просто компилятор выдаст предупреждение, что эта переменная помечена как «Not Null», а вы пытаетесь присвоить эй null.
Сам тип string символ "?" никак не меняет.

Более того, если я попытаюсь использовать сборки скомпилированные в C#8 из C#7, то все поля помеченные как «string?» будут видны как обычные «string» и накаких предупреждений (или ошибок компиляции) не будет, если я попытаюсь присвоить им null.

string? это тот же тип string, между ними нет разницы

но int? это действительно другой тип — Nullable.

Это как раз та путаница, о которой я говорил в предыдущих комментариях.
Вот оригинальный текст:
Теперь самый важный вопрос: что же поменялось в IL? С точки зрения исполняемого кода — ничего! Но с точки зрения метаданных поменялось конечно: теперь в типе который использует nullable аннотации все типы которые являются nullable проаннотированы атрибутом [Nullable]. Сделано это по понятным причинам: чтобы потребители вашего кода могли использовать ваши аннотации.


Этот string существует и в исходном коде и в рантайме.
По сути запись:
public string? MyProperty { get; set; } = null;

это синтаксический сахар для:
[System.Runtime.CompilerServices.NullableAttribute]
public string MyProperty { get; set; } = null;


Кстати, по поводу:
… заменяемые на ValueTuple с потерей информации об именах свойств

имена свойств не теряются, они сохраняются в метаданных.
string? это не анонимный тип, это обычный string.

Под анонимными типами в C# понимается совершенно другая вещь, например:
var myVariable = new {Field1 = "Field 1", Field2 = 2};

увидев такой код, компилятор создаст тип:
    class ___AnonymusXXXX
    {
        public string Field1 {get; private set;}
        public int Field2 {get; private set;}
    }

Эта ветка начиналась с напоминания о том, что были и другие варианты как реализовать nullable ref types.
Идея помечтать обязательные поля "!" имеет обратную совместимость и не требует костылей в виде опций компилятора.

Не совсем понял про анонимный тип: в примере тип переменной это string и он никакой не анонимный.
Для Value Types, "?" — это синтаксический сахар для структуры Nullable<>:

int? = Nullable<int>

Для Reference Types, "?" — это просто подсказка компилятору + добавляется [NullableAttribute] (подсказка компилятору при испльзовании кода из других сборок)

Разница ещё в том, что в Value Types "?" логически относится к типу, а в случае с Refernce Types к переменной, полю или методу, так, что с точки зрения логики, надо было бы писать:

string myVariable? = null

a не

string? myVariable = null
Вот у вас есть существующий класс
class MyClass
{
   public string Id;
   public SomeType1 Property1;
   public SomeType2 Property2;
   ...
   public SomeTypeN PropertyN;
}


Глядя на этот класс я с большой долей вероятности могу сказать какое поле, скорее всего является, обязательным.

Какие поля являются «не обязательными» нужно выяснять разбирая код программы.

Теперь я включаю эту новую опцию, и получаю кучу предупреждений при попытке собрать проект. Дальше есть 4 варианта:
1) Забить на предупреждения (тогда зачем это все?)
2) Пометить все поля как "?" (тогда зачем это все?)
3) Отключить эту опцию (тогда зачем это все?)
4) Потрать кучу времени на рефакторинг работающей и отлаженной программы (здорово конечно, но надолго ли вас хватит).
Я согласен, что вариант с "!" не идеален как и любое компромиссное решение, но им хотя бы можно было безболезненно начать пользоваться постепенно обновляя существующую кодовую базу.

Сейчас же, многие просто не будут включать эту опцию в уже существующих проектах потому как понять, где нужно ставить “?”, а где не нужно, зачастую очень сложно.

Information

Rating
Does not participate
Registered
Activity