Make the constructors of the Policy abstract base classes protected, not internal [allow custom policies]
See original GitHub issueThe constructors of the Policy
and Policy<TResult>
abstract base classes are internal
but should be made ~public~protected
.
This would allow users to implement new custom policies, outside of the Polly package, deriving from these base classes.
Needed in files Policy.cs
, Policy.TResult.cs
, PolicyAsync.cs
, PolicyAsync.TResult.cs
.
Issue Analytics
- State:
- Created 6 years ago
- Comments:7 (5 by maintainers)
Top Results From Across the Web
Constructor of an abstract class in C# - Stack Overflow
when declaring public constructors in abstract classes however it will not allow creating a new instance.
Read more >Access modifier of abstract class constructors
It seems like the access modifier is superfluous and should be implicitly protected since it can only be used from within a derived...
Read more >Constructors of an "abstract" class should not be declared ...
Abstract classes should not have public constructors. Constructors of abstract classes can only be called in constructors of their subclasses.
Read more >CA1012: Abstract types should not have public constructors
Rule description Constructors on abstract types can be called only by derived types. Because public constructors create instances of a type and ...
Read more >Are protected fields really bad practice? : r/java
The abstract class has a few fields which are exclusively used in the subclasses. We are forced to make them private and use...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Thanks all for all the great comments. Hoping to come back to this and #299 before the end of the week.
Closed by #391
The options for compenentisation discussed in the previous comment (thanks for the valuable discussion) remain options for a future version of Polly or any similar product. As discussed above, a rewrite to such a structure would be intellectually well motivated (and does appeal). It would require a significant chunk of time tho (and would lead to a significantly different syntax experience for users).
( EDIT: Very happy to discuss any ideas around this, and/or support anyone who wants to explore them. )