Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the ability to prioritize decorators #255

Closed
ipjohnson opened this issue Mar 29, 2020 · 3 comments
Closed

Add the ability to prioritize decorators #255

ipjohnson opened this issue Mar 29, 2020 · 3 comments

Comments

@ipjohnson
Copy link
Owner

Current you can prioritize exports but you can't prioritize decorators. It should be easy enough to add a fluent configuration method to allow this.

This was brought up in issue #253

@ipjohnson
Copy link
Owner Author

This is implemented

@shahabganji
Copy link

@ipjohnson thanks for this feature 🙏

Priority method overrides the order of decorators registrations. This is still globally ordering the decorators and one cannot customize it per implementations, right?

Consider the following rare scenario:

public interface ICommand<T>{
    void Handle(T data);
}

[Audit]
[Log]
public class FirstCommand: ICommand<string> { ... } 


[Database]
[Log]
[Audit]
public class SecondCommand: ICommand<string>{ ... }

And there are three other decorators implementing the ICommand<T> and with .When.MeetsCondition, an example discussed earlier, they have been customized to be created on the existence of the corresponding attribute on top of the implementations. Is there any way that the order of decorators being based on the order of attributes? For instance, when creating decorators for FirstCommand the order be Audit -> Log but for the SecondCommand it should be the other way: Database -> Log -> Audit.

is it at all possible and reasonable?

Thanks.

@ipjohnson
Copy link
Owner Author

Sadly attribute order is not preserved as part of the language specification.

"The order in which attributes are specified in such a list, and the order in which sections attached to the same program entity are arranged, is not significant. For instance, the attribute specifications [A][B], [B][A], [A,B], and [B,A] are equivalent."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants