Или могут? Или нельзя, но иногда можно?

Здравствуйте, vaa, Вы писали:

vaa>Или могут? Или нельзя, но иногда можно?
Давайте разберёмся. Свойство — это пара методов со специальным синтаксисом вызова, похожим на обращение к полю.
Можно обратно деконструировать их до методов:

public abstract class Sample<T> 
{
   public abstract void SetA(T value);
   public abstract T GetA();
}

Теперь можно сделать эти методы асинхронными:

public abstract class Sample<T> 
{
   public abstract Task SetA(T value) {};
   public abstract Task<T> GetA() {};
}

Из сигнатур методов видим, что превратить эти методы обратно в свойство не получится, т.к. у них неподходящие сигнатуры.
Сделать read-only асинхронное свойство можно:

public abstract class Sample<T> 
{
   public abstract Task SetA(T value) {};
   public abstract Task<T> A {get};
}

   Sample<int> sample = ...;
   var v = await sample.A; // type of v = int;

Но вот асинхронную установку значения в таком стиле сделать не выйдет.

   Sample<int> sample = ...;
   await sample.A = 42; // oops!
   await sample.SetA(42); // ok

Tсли бы это было возможно, как бы должен был работать код типа такого:

   Sample<int> sample = ...;
   await sample.A += 5; // oops!

Будет ли там 2 await двух методов, выполненные один за другим?


Общее мнение команды C# — async свойства не нужны. См. тж. https://github.com/dotnet/roslyn/issues/3015

Здравствуйте, Sinclair, Вы писали:

S>Tсли бы это было возможно, как бы должен был работать код типа такого:
S>

S>   Sample<int> sample = ...;
S>   await sample.A += 5; // oops!
S>

S>Будет ли там 2 await двух методов, выполненные один за другим?

Это еще можно решить.

S>Общее мнение команды C# — async свойства не нужны. См. тж. https://github.com/dotnet/roslyn/issues/3015

Главное — свойства рекомендуется делать легкими, без сложных вычислений внутри.

в чем тормозит тебя их отсутствие?

Здравствуйте, 尿컙拋㕪⬎⤇Ǥ꧃푙刾ꄔ൒, Вы писали:

尿Ǥ푙>в чем тормозит тебя их отсутствие?

Проблема в том, что св-ва вещь в себе, а дотнет насквозь уже асинхронный, и вот в св-ве которое вроде бы методы обычные(на самом деле нет),
нужно вызвать асинхронный код, и это больно.
Тут я согласен с ЯП зиг в том, что кол-во неявного уже зашкаливает в современных ЯП.
Взять тот же F# https://github.com/elmish/Elmish.WPF
как-то обходится без св-в, которые как я подозреваю завезли только в угоду winforms.

Мало что понял, но свойства это стейт, дальше вы понимаете. Взять тот же vanilla JS там нет свойств. Методы из свойств вызывать не надо (ну, кроме NotifyPropertyChanged и ему подобных) и все само пройдет. Теоретически все можно сделать асинхорнным, типа

await obj.Property = value; // на случай, если сеттер имеет вызов асинхронного метода

эта парадигма должна приниматься всем стаком, байндингами, контролами и так далее. Блоки ранее синхорнного кода больше не синхронным — представьте заполнили форму и засабмитили — и перед валидацией — бах и сплаш скрин — Ждите заполнения

Или привидите менее абстрактный пример, где это мешает.

尿Ǥ푙>Или привидите менее абстрактный пример, где это мешает.

Может быть что-то типа FileStream.Position
https://referencesource.microsoft.com/#mscorlib/system/io/filestream.cs,1241
Там внутри вызывается FlushWrite, содержащий асинхронный код, вызванный синхронно.

По-хорошему Position должно быть асинхронным свойством методом.

M>По-хорошему Position должно быть асинхронным свойством методом.

Я не знаю контекста, могу ошибаться, но на общих снованих и во озбежание кривотолков не лучше сделать как: async GetPosition() ?

хотя я вижу часто это что при конвертации свойств в методы оставлают неизмененные имена — почти норма сейчас js такого много.

M>>По-хорошему Position должно быть асинхронным свойством методом.

尿Ǥ푙>Я не знаю контекста, могу ошибаться, но на общих снованих и во озбежание кривотолков не лучше сделать как: async GetPosition() ?

Ну да, тогда уж GetPositionAsync
Но вообще мой комментарий про то, что если свойства унаследованы от базового класса, интерфейса (FileStream от Stream), то с эти уже ничего не поделаешь.
Можно конечно переопределить их как NotSupported или пометить как obsolete, но это не везде подойдет.

c’est la vie use extension methods instead.

Здравствуйте, m2user, Вы писали:

尿Ǥ푙>>Или привидите менее абстрактный пример, где это мешает.

M>Может быть что-то типа FileStream.Position
M>https://referencesource.microsoft.com/#mscorlib/system/io/filestream.cs,1241
M>Там внутри вызывается FlushWrite, содержащий асинхронный код, вызванный синхронно.
Афаик, уже нет. Вот этот код синхронизации позиции в управляемой обёртке с файл-хэндлом уровня ОС очень дорого стоит. Поэтому в одном из релизов (то ли 6, то ли 7) его выпилили.

Здравствуйте, 尿컙拋㕪⬎⤇Ǥ꧃푙刾ꄔ൒, Вы писали:
尿Ǥ푙>эта парадигма должна приниматься всем стаком, байндингами, контролами и так далее. Блоки ранее синхорнного кода больше не синхронным — представьте заполнили форму и засабмитили — и перед валидацией — бах и сплаш скрин — Ждите заполнения

尿Ǥ푙>Или привидите менее абстрактный пример, где это мешает.

https://www.mudblazor.com/components/datepicker#input-masking
вот есть компонент, здесь конечно не увидеть, но если запустить пример в режиме blazor server, то состояние уезжает на сервер, маска соотвественно тоже,
под капотом посмотрел, в сеттерах библиотеки используется SomeTask(value).FireAndForget() для вызова изменений, если в консоли бразуера поставить 3g троллинг и начать сколько-нибудь быстро вводить дату
курсор-сволочь начинает отпрыгивать на символ назад. Все потому, что await не доступен в сеттере.
В философии вон идет обсуждение джавовых тредов, которые будут ожидаться без дополнительных ключевых слов.

尿Ǥ푙>>Или привидите менее абстрактный пример, где это мешает.

vaa>https://www.mudblazor.com/components/datepicker#input-masking
vaa>вот есть компонент, здесь конечно не увидеть, но если запустить пример в режиме blazor server, то состояние уезжает на сервер, маска соотвественно тоже,
vaa>под капотом посмотрел, в сеттерах библиотеки используется SomeTask(value).FireAndForget() для вызова изменений, если в консоли бразуера поставить 3g троллинг и начать сколько-нибудь быстро вводить дату
vaa>курсор-сволочь начинает отпрыгивать на символ назад. Все потому, что await не доступен в сеттере.
vaa>В философии вон идет обсуждение джавовых тредов, которые будут ожидаться без дополнительных ключевых слов.

И чем бы тут помог await, если всё равно нужно ждать выполнения сеттера, хоть синхронно, хоть асинхронно?
Если же не обязательно ждать, то что мешает вызвать setter на threadpool потоке и не ждать его завершения.

Здравствуйте, vaa, Вы писали:

vaa>Или могут? Или нельзя, но иногда можно?

Свойства подразумевают короткие, локальные операции с состоянием. Если есть удаленные вызовы, например, БД — то это уже не должно представлятся всего лишь свойством, а должен быть метод.

Здравствуйте, Aquilaware, Вы писали:

A>Здравствуйте, vaa, Вы писали:

vaa>>Или могут? Или нельзя, но иногда можно?

A>Свойства подразумевают короткие, локальные операции с состоянием. Если есть удаленные вызовы, например, БД — то это уже не должно представлятся всего лишь свойством, а должен быть метод.
выполнение async вполне может быть и коротким и локальным.

Здравствуйте, vaa, Вы писали:
vaa>выполнение async вполне может быть и коротким и локальным.
А в чём тогда смысл делать его async?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, vaa, Вы писали:
vaa>>выполнение async вполне может быть и коротким и локальным.
S>А в чём тогда смысл делать его async?
Потому что потребляемый код требует. Практически весь дотнет переписали на асинки.
Порой просто нет выхода.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, vaa, Вы писали:
vaa>>выполнение async вполне может быть и коротким и локальным.
S>А в чём тогда смысл делать его async?
https://github.com/MudBlazor/MudBlazor/blob/d381e778ad1802ee032ce94747b6ea764daffcf4/src/MudBlazor/Components/DatePicker/MudDatePicker.cs#L27
Вот из-за этого кода на медленном соединении курсор отскакивает назад, потому что состояние UI и состояния теряет согласованность.

Здравствуйте, vaa, Вы писали:

vaa>Или могут? Или нельзя, но иногда можно?
Тут вопрос такой, а почему нельзя? В чем проблема. И уже от этого отталкиваться.
То есть Task то можно, а почему нельзя async.
Понятно, что async это про автомат, но возращает то он Task

Здравствуйте, vaa, Вы писали:
vaa>https://github.com/MudBlazor/MudBlazor/blob/d381e778ad1802ee032ce94747b6ea764daffcf4/src/MudBlazor/Components/DatePicker/MudDatePicker.cs#L27
vaa>Вот из-за этого кода на медленном соединении курсор отскакивает назад, потому что состояние UI и состояния теряет согласованность.
А точно замена проперти на асинк чем-то поможет?
Может быть, надо заменить вот так:

set => SetDateAsync(value, true).Wait();

?