Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, samius, Вы писали:
S>>А почему вообще не Action disposeAction? Зачем T?
S>Перегрузка без параметра тоже есть. Как я понял, новая перегрузка — это сахар для S>
S>using(Disposable.Create(someResource, r => r.Close())) {...}
S>
S>По аналогии с factory-методами для тасков (из события и тыды).
Здравствуйте, Sinix, Вы писали:
S>Порядок аргументов лучше свапнуть и state в source | arg переименовать.
Порядок аргументов и название state взято на примерах от майкрософта. У них везде action идет первым, а аргумент, передаваемый в делегат — после. Сделал также, что соблюдался общий стиль. Вот примеры :
Ну и сами классы тасков, конструкторы и прочие методы такие как ContinueWith все сделаны единообразно, и соответственно, я свое ничего придумывать не стал и отступать от общего стиля тоже не стал, да и название для аргумента назвал так как используется — state.
S>UPD и State после диспоза очищать. Иначе утечка будет.
Да, не доглядел
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Re[3]: 2 rameel: Disposable.Create, порядок аргументов
Здравствуйте, rameel, Вы писали:
R>Здравствуйте, samius, Вы писали:
S>>А почему вообще не Action disposeAction? Зачем T?
R>Для того, чтобы избежать создания замыкания там и когда это необходимо.
Благодярю! Не подумал об этом.
Может быть актуально в борьбе с implicitly captured closure.
Re[2]: 2 rameel: Disposable.Create, порядок аргументов
Здравствуйте, rameel, Вы писали:
S>>Порядок аргументов лучше свапнуть и state в source | arg переименовать.
R>Порядок аргументов и название state взято на примерах от майкрософта. У них везде action идет первым, а аргумент, передаваемый в делегат — после.
Аргумент, причём убойный
Даже в Task.FromAsync() callback первыми идут, память подвела. И менять порядок аргументов при перегрузках тоже не рекомендуется.
Тогда оставляем как есть.
S>>UPD и State после диспоза очищать. Иначе утечка будет. R>Да, не доглядел
Ок и спс