Talk:Aspect oriented programming
What is the task here? --Rdm 19:10, 9 June 2011 (UTC)
- While it does have some code examples, I think this is supposed to be more of an informational page. It's not marked as a task, but it was made by an anonymous user who probably didn't know the process. --Mwn3d 20:39, 9 June 2011 (UTC)
- It's not very informational either. It doesn't say what AOP is or why you might want to do it, but at least it includes a long rambly example in C, a language which I'd have called inimical to AOP in the first place… I can't even tell if that's because they “get it” much more profoundly than me, or much less. The evidence is consistent with both interpretations! –Donal Fellows 23:57, 9 June 2011 (UTC)
- I only made a guess at intent. I can't say anything about the quality. I don't understand AOP very well either. If someone wanted to improve the info here that'd be great. --Mwn3d 01:05, 10 June 2011 (UTC)
- In my experience, AOP is an attempt to address the issues a person might want to address using a Domain Specific Language, but without the conciseness, nor the modularity (with strong lip-service to the concept of modularity, but what I have seen in implementations does not align with my feelings about modularity). Now, granted, the theory (MVC++) usually sounds great, but the examples I have seen (Observer++) have made me want a good DSL implementation. -- --Rdm 11:31, 10 June 2011 (UTC)
- AOP allows you to wrap cross-cutting functionality round other code without disrupting that other code particularly. The way in which it is most strongly used in frameworks like Spring is to provide transactions round methods, so that all a method has to do is to work with the data and let the aspect handle the transaction (including things like rolling the changes back if an exception is thrown). Having tried to write transaction-handling code without AOP, using an aspect to handle it is far simpler; it's genuinely difficult to get transaction handling correct and it makes the code very ugly when you do, but splitting it off into its own concern (the “aspect”) means that the business logic is separated from the complexity. It's also used for things like logging, cacheing, security enforcement, etc. All things that are typically orthogonal to the core of what's going on. The degree to which aspects should be applied transparently or with some kind of explicit marker is something which seems to divide practitioners; I'm more of an “explicit” guy as its easier to see what's going on when maintaining the code… –Donal Fellows 15:18, 10 June 2011 (UTC)
- In my experience, AOP is an attempt to address the issues a person might want to address using a Domain Specific Language, but without the conciseness, nor the modularity (with strong lip-service to the concept of modularity, but what I have seen in implementations does not align with my feelings about modularity). Now, granted, the theory (MVC++) usually sounds great, but the examples I have seen (Observer++) have made me want a good DSL implementation. -- --Rdm 11:31, 10 June 2011 (UTC)
- I only made a guess at intent. I can't say anything about the quality. I don't understand AOP very well either. If someone wanted to improve the info here that'd be great. --Mwn3d 01:05, 10 June 2011 (UTC)
- It's not very informational either. It doesn't say what AOP is or why you might want to do it, but at least it includes a long rambly example in C, a language which I'd have called inimical to AOP in the first place… I can't even tell if that's because they “get it” much more profoundly than me, or much less. The evidence is consistent with both interpretations! –Donal Fellows 23:57, 9 June 2011 (UTC)
- Ok, I suppose that works -- Spring, in essence, is a DSL. No reason they can't be combined. --Rdm 16:02, 10 June 2011 (UTC)
- Maybe the task is to identify features of aspect oriented programming that the language supports. We probably don't need any specific application in mind. There are a variety of methods mentioned in the task description, so implementers could probably use that as a guideline --Markhobley 16:13, 10 June 2011 (UTC)
- a generic description of features is surely useful, but for language comparison a more specific problem would be nice. it would enable implementers to demonstrate alternative ways to solve the problem if the language does not support aspect oriented programming directly.
- a possible task could be: you have a library whose source you can not change, and you want to print a trace of the function execution that happens in the library. the task is to print each function call and its arguments before they are happening. (a backtrace that may be provided by the language is not acceptable)
- this task is i believe suitable for aspect oriented programming as it requires to intercept the function calls without changing the code in the functions. however implementers are free to take advantage of any language feature to solve the problem, thus allowing the reader to not only learn about aspect oriented programming features but also find out how the problem can be solved if the language does not support aspects directly.--eMBee 02:27, 13 October 2011 (UTC)
Comment on the task as it stands
This reads like an encyclopedia article only masquerading as a task. If someone had taken an example of Aspects at work in a language that supported it such as "Specman e" then they could have honed in on the features and asked for the like in other languages. as a description of aspect orientism in programming, again it lacks a concrete example and comparisons. Just my thoughts. --Paddy3118 04:26, 13 October 2011 (UTC)