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

[Suggestion] A general AOP inplementation structure, please #3356

Closed
ghost opened this Issue Jun 6, 2015 · 8 comments

Comments

Projects
None yet
5 participants
@ghost
Copy link

ghost commented Jun 6, 2015

I know that we can use dynamic AOP structure such as "Dynamic Proxy", however that is a heavy bag for me. And to be honest, any dynamic compiling will need an interface to do AOP's injection. So if I have too many methods for AOP (such as do auto logging), I have to define so many interfaces or virtual methods.....and consider that Microsoft seems to like "trick" in syntax such as C#'s LINQ, Async……It would be better if Microsoft can:

  1. Define an Attribute or an interface that contains: DoBeforeExecute, DoExecute and DoAfterExecute.
  2. Any method, class with the attributes will be automatcially do these steps, when the method is called.
  3. When compiling, these customized attributes will be "injected" into your IL (Something like PostSharp, however PostSharp needs money and you see that this is a very important thing sometimes).

I think NET's framework's everything is good except for a general AOP framework. So it's a necessary thing for Microsoft to add this very important into your framework. Maybe Roslyn would be nicer, if this function is injected. And I also know that is a huge task, so since the open source begins with the latest version of Roysln, Maybe Microsoft can develop these open things for our "second-hand" improve.

Hope this will be the SELL POINT or FEATURE for Visual Studio;)

@dsaf

This comment has been minimized.

Copy link

dsaf commented Jun 10, 2015

"...however PostSharp needs money and you see that this is a very important thing sometimes..."

PostSharp FAQ:

"We allow selected open-source projects to use and redistribute PostSharp for free, even Pro Edition features. Developers using the project will not be required to register or acquire a license as long as they use PostSharp in conjunction with the project."

@ghost

This comment has been minimized.

Copy link
Author

ghost commented Jun 10, 2015

@dsaf
First I have to say that I only give PostSharp a sample, which proves that such a function is very important for a general architecture. So this should be a function nested in Visual Studio.
Second, this only due to the open-source projects ;)

@vladkosarev

This comment has been minimized.

Copy link

vladkosarev commented Sep 4, 2015

Yes please! Bake this is into the whole .net stack. That would be a fantastic feature.

@Console32

This comment has been minimized.

Copy link

Console32 commented Oct 11, 2015

I would love to see that a feature of the .net stack.

@pootow

This comment has been minimized.

Copy link

pootow commented Nov 5, 2015

PLEASE make this happen!!

@gafter

This comment has been minimized.

Copy link
Member

gafter commented Nov 20, 2015

This will likely happen as a community contribution shortly after #5292 and #5561.

@gafter

This comment has been minimized.

Copy link
Member

gafter commented Mar 24, 2017

We are now taking language feature discussion in other repositories:

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

I am not moving this particular issue because I don't have confidence that the LDM would likely consider doing this in the form proposed. I would expect that, once (if/when) source generators become a language feature, there would be an add-on using that to handle these use cases.

@gafter gafter closed this Mar 24, 2017

@ghost

This comment has been minimized.

Copy link
Author

ghost commented Mar 25, 2017

Nothing special, however would you mind linking this to dotnet/csharplang#107 instead of closing it simply? Just make it as a backup idea.

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