AOP use cases

[Bryan]

Dave Kuhlman wrote:

> Michael Walter wrote:
> 
> 
>>Bryan wrote:
>>
>>>>Those of you using XML might want to visualize the program as a
>>>>DOM tree and
>>>>AOP as applying a XSLT stylesheet. (Now visualize applying
>>>>several different
>>>>stylesheets in arbitrary order)
>>>>
>>>>
>>>>Daniel
>>>>
>>>
>>>
>>>thank you for this explanation... it's the best explanation i've
>>>heard yet and now i have a grasp and can visualize what AOP is.
>>>
>>>bryan
>>
>>That sounds like a description of (CL/Scheme-style) macros :)
> 
> 
> So, arbitrarily complex transformations on the source code with
> the intent of hiding the intension of the source code are good,
> right?
> 
> I wish I could say something to satirize this.  But, the post
> about XML/XSLT seems satirical enough.
> 
> Dave
> 


for me, i thought it was some really new cool concept.  i was swimming in buzz words like "separation of concerns" and 
having trouble getting to the meat of what it really was.  but then it turns out that all it is nothing more than 
XML/XSLT, oops, i mean "Java/AOPT".   of course when you think this way, you easily see why logging is always chosen as 
the perfect example.  i just cannot see this as part of a general purpose programming technique.  in some funcky way, 
it's like factoring sideways instead of factoring up... does that make any sense?  how can an "AOPT" keep up with my 
functions, methods, callbacks, messages, queues, events, xmlrpc calls, c extensions, etc.   how can an AOPT writer write 
generic code unless the data supports some strict interface so it can be transformed.  then if you must have a strict 
interface, why not use some other OOP technique.  dang, this is insane once you really think about it.  if someone can 
help me see something that i'm missing i really welcome the feedback.

bryan