Support Decorators about stronginject HOT 7 CLOSED

@YairHalberstadt I don't want to intrude, but deterministic ordering (whatevet it is) seems important, no?

from stronginject.

@dadhi how would you recommend we meaningfully order the decorators? I.e the ordering will happen to be deterministic, if only because StrongInject is deterministic, but should there be a specific order in which they should run, and which is simple for users to understand and reorder?

If not I would suggest to make sure your decorators do not depend on running in a particular order.

from stronginject.

I don't want to intrude

On the contrary, you're input is highly valued! It's great to have the opinion of someone whose spent far more time working on IOC containers than I have!

from stronginject.

Note that attributes are not considered to be ordered by the CLI spec, so I would prefer not to depend on the order of attributes.

from stronginject.

On the contrary, you're input is highly valued! It's great to have the opinion of someone whose spent far more time working on IOC containers than I have!

Thanks. I wanted to speak because you are formulating the feature similar to what I did and thought 3 years ago. Now I know more. And the most important thing that Decorators (in a wider sense) are super powerful and provide a user-driven customization without introducing ad-hoc features into containers. To name a few - custom initializing and disposing logic.

If not I would suggest to make sure your decorators do not depend on running in a particular order.

It is not always possible.

Note that attributes are not considered to be ordered by the CLI spec, so I would prefer not to depend on the order of attributes.

For attributed registrations you may consider adding int? RelativeOrder (the name is just an example) attribute property to guarantee the order if orderA > orderB and not guarantee the order if property is not set.
I did this myself for the attributed registrations in my lib (which are supported via MEF based extension).

from stronginject.

@YairHalberstadt

that Decorators (in a wider sense)

What I mean here and relating to the fact that you already have a support for factory methods:

• "Decorator" for A maybe a constructor of type implementing A and accepting the A as parameter.
• "Decorator" for A maybe a factory method returning A and accepting the A as parameter.
• "Decorator" constructor or factory method may accept other parameters which help to serve the decoration process (configs, services, etc.)
• "Decorator" of A does not support decoration of multiple A parameters.

Thats it :)

Enabling the unified support for the factory method decorators provides a natural (user-customized) creation pipelines.

Again I don't want to drive your design, consider this just an info sharing.

from stronginject.

Thanks for the input @dadhi

I think there's definitely quite a few further things that need to be hashed out: for example how do we order decorators defined in seperate modules? Is this order parameter global? If so it becomes very unwieldy to pick it since you need to know the order of all other decorators to pick your order correctly.

Perhaps it will be enough to say that the order of decorators is only defined within a module. The order of decorators defined in different modules is arbitrary (but deterministic).

from stronginject.