public static IDisposable Create<T>([NotNull] Action<T> disposeAction, T state)

Порядок аргументов лучше свапнуть и state в source | arg переименовать.

UPD и State после диспоза очищать. Иначе утечка будет.

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


S>

S>public static IDisposable Create<T>([NotNull] Action<T> disposeAction, T state)
S>

S>Порядок аргументов лучше свапнуть и state в source | arg переименовать.

А почему вообще не Action disposeAction? Зачем T?

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

S>А почему вообще не Action disposeAction? Зачем T?

Перегрузка без параметра тоже есть. Как я понял, новая перегрузка — это сахар для

using(Disposable.Create(someResource, r => r.Close())) {...}

По аналогии с factory-методами для тасков (из события и тыды).

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

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

S>>А почему вообще не Action disposeAction? Зачем T?

S>Перегрузка без параметра тоже есть. Как я понял, новая перегрузка — это сахар для
S>

S>using(Disposable.Create(someResource, r => r.Close())) {...}
S>

S>По аналогии с factory-методами для тасков (из события и тыды).

Я понимаю, для чего. Я не понимаю, почему не

using(Disposable.Create(() => someResource.Close())) {...}

Иными словами, какой смысл делать перегрузку с параметрами? Что такого можно записать с параметрами, чего нельзя записать без них и короче?

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

No idea why. Но раз добавлено — то хотя бы сделать это стильно

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

S>А почему вообще не Action disposeAction? Зачем T?

Для того, чтобы избежать создания замыкания там и когда это необходимо.

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

S>Порядок аргументов лучше свапнуть и state в source | arg переименовать.

Порядок аргументов и название state взято на примерах от майкрософта. У них везде action идет первым, а аргумент, передаваемый в делегат — после. Сделал также, что соблюдался общий стиль. Вот примеры :

https://msdn.microsoft.com/en-us/library/dd321663

// CancellationToken class:
public CancellationTokenRegistration Register(
    Action<object> callback,
    object state)

https://msdn.microsoft.com/en-us/library/dd321456

// TaskFactory class:
public Task StartNew(
    Action<object> action,
    object state)

https://msdn.microsoft.com/en-us/library/dd321266(v=vs.110).aspx

// TaskFactory<TResult> class:
public Task<TResult> StartNew(
    Func<object, TResult> function,
    object state)

Ну и сами классы тасков, конструкторы и прочие методы такие как ContinueWith все сделаны единообразно, и соответственно, я свое ничего придумывать не стал и отступать от общего стиля тоже не стал, да и название для аргумента назвал так как используется — state.

S>UPD и State после диспоза очищать. Иначе утечка будет.

Да, не доглядел

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

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

S>>А почему вообще не Action disposeAction? Зачем T?

R>Для того, чтобы избежать создания замыкания там и когда это необходимо.

Благодярю! Не подумал об этом.
Может быть актуально в борьбе с implicitly captured closure.

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

S>>Порядок аргументов лучше свапнуть и state в source | arg переименовать.

R>Порядок аргументов и название state взято на примерах от майкрософта. У них везде action идет первым, а аргумент, передаваемый в делегат — после.
Аргумент, причём убойный
Даже в Task.FromAsync() callback первыми идут, память подвела. И менять порядок аргументов при перегрузках тоже не рекомендуется.
Тогда оставляем как есть.

S>>UPD и State после диспоза очищать. Иначе утечка будет.
R>Да, не доглядел
Ок и спс