Generalizing as a tool about asyncgenerator HOT 9 CLOSED

Currently I am planning to support configuring the generator via xml and yaml format.
Here you can find a complete example of a configuration file in xml format and here the same configuration in yaml format.
As I am not familiar with yaml, what naming convention should we use?

In order to completely configure the generation via a configuration file we need a way to include custom plugins into it (example). In the current configuration file we are able to only reference a plugin inside an assembly, but we are not able to add an implementation inside the configuration file yet. I was thinking to add a special section inside the configuration file where we would include the plugin code and it would be compiled in runtime with the Roslyn Scripting API. What do you think about it?

from asyncgenerator.

With attributes we are very limited in expressing the wanted behavior. For example with an attribute we could mark a specific method to be ignored or generated as async, but what about ignoring methods inside a specific namespace, should we use assembly attributes?

Where should the attributes be declared, probably not in the generator itself as nobody want to have an extra dependency?

What are the desired functionalities that should be possible to do with marking attributtes?

from asyncgenerator.

With attributes we are very limited in expressing the wanted behavior.

Yes, It's true, but I think in even NHibernate's case they shall be enough.

but what about ignoring methods inside a specific namespace, should we use assembly attributes

Yes, assembly attributes, or, the configuration options

Where should the attributes be declared, probably not in the generator itself as nobody want to have an extra dependency?

I think in some extra assembly, or, even better source package (pretty much like JetBrains.Annotations.Portable). We, in any way, need to provide an additional implementation for the async lock. We can mark these attributes with an [Condiational] attribute and a package itself as a dev dependency.

What are the desired functionalities that should be possible to do with marking attributtes?

I was thinking about following:

• Mark an exceptional generation strategy for a type (Ignore, New type, Partial, etc)
• Mark an exceptional generation strategy for a method (Ignore, to async)
• Mark a hint (by a name) how to find an async counterpart for a method ([AsyncCounterpart(nameof("XXX.YYYAsync"), Type=...,])

Also, I was thinking about the options file like in sharpen (it's just a way to read the CLI options from a file, not from command line):

-ignoreMethod: NamespaceName.TypeName.MethodName
-ignoreNamespace: ...

from asyncgenerator.

Another idea: as the configuration for each particular use case will be static (or mostly static) it would make sense to make this configurable by some configuration file with a format which supports hierarchical data (yml, json, etc).

from asyncgenerator.

For now I will go with a configuration file that will mimic the configuration done by code (example).
At the bottom of the example we can define rules for methods and types in case we need the same rule multiple times.

With this configuration file one can easily create its own attribute marking for an exceptional generation strategy for a type or method.

Mark a hint (by a name) how to find an async counterpart for a method ([AsyncCounterpart(nameof("XXX.YYYAsync"), Type=...,])

I suppose that the purpose of this attribute is to specify the location of the async counterpart when it is located in a different type (eg. extension method)?
For invoked external methods we would need to specify the attribute on the assembly level which IMO is not ideal.

For extensions methods I will probably create an option where we could specify our async extension methods in order to avoid writing a custom plugin.

from asyncgenerator.

what naming convention should we use?

So, there is no pre-defined or one-fits-all style according to answers to this question.

I, personally, would choose camelCase as closest to the C#.

In the current configuration file we are able to only reference a plugin inside an assembly, but we are not able to add an implementation inside the configuration file yet.

I think plugins through assembly would be enough for most cases

from asyncgenerator.

Can you open a PR from the feature branch (just to enable conversations)

from asyncgenerator.

Can you open a PR from the feature branch (just to enable conversations)

Opened

I think plugins through assembly would be enough for most cases

I agree, but if someone has only one simple plugin to add, it would be less painful to add it in the configuration file rather creating its own assembly just for that. As it is very easy to implement this feature I will add support for it.

from asyncgenerator.

Closed by #21 & #25

from asyncgenerator.