The Artima Developer Community
Sponsored Link

Java Buzz Forum
More on Extreme AOP

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Carlos Villela

Posts: 116
Nickname: cvillela
Registered: Jun, 2003

Carlos Villela is a Java developer working mostly with web technologies and AOP.
More on Extreme AOP Posted: Jun 26, 2003 5:08 PM
Reply to this message Reply

This post originated from an RSS feed registered with Java Buzz by Carlos Villela.
Original Post: More on Extreme AOP
Feed Title: That's sooo '82!
Feed URL: http://www.jroller.com/rss/cv?catname=Technical
Feed Description: Carlos Villela's weblog. Everyday life, everyday software development, everyday musings.
Latest Java Buzz Posts
Latest Java Buzz Posts by Carlos Villela
Latest Posts From That's sooo '82!

Advertisement
Cedric posted some really interesting thoughts about my latest AOP ideas. I specially like the names Extreme AOP and Quantum AOP. If everything turns out as I expect, I'll probably get a patent over this and enter the Top 10 Filthiest Richest Motherfuckers list :)

One thing that kept spinning in my head is the problem with excessive casting (you need to explicitly cast objects to the introduced interface you want in order to call any method or access any property). Again, Cedric hits the spot:

The million-dollar question is:  when you decide you want to shoot for an ultra-modular architecture such as the one Carlos is pursuing, is Java the right language?

I believe Java is not the right language, but the right platform. I mean, using Java (the language) leads me to that casting hell we already discussed. The simplest solution, then, is to use a different language, like BeanShell, JavaScript or anything else supported by the Bean Scripting Framework. Being a JavaScript fan, I must say that Rhino is a really good implementation, and I'll probably stick with it, but I'm not going away from my JVM or servlet container anytime soon. Oh, and by the way, I was already using Velocity with my composed business objects, and it works just fine - but, as expected, Velocity is limited to the presentation tier only, and that solves just a part of the problem.

So, I went to take a look at what WebWork holds for me in the scripting area. Awesome - Rickard implemented BSF Actions already. He just forgot to document it - no mention of this feature anywhere on WebWork's site or documentation, but that's OK, everyone that reads WW's documentation understands that they need to look at the code if they want to understand how things really happen - at least WebWork's code is a joy to read: very very easy to understand :D

If I understood the code correctly, all of the POSTed or GETted values end up in the scripting context, and the only contract the script must fulfill is having a "result" variable with the view name to redirect the client. Can you imagine a simpler solution? :)

Okay, we still have a problem with business logic here. I don't want my business logic mixed up with WebWork actions, but it's in the business logic that my casting hell is going to get really bad. Ok, I'm doing Extreme AOP already, why not Extreme Scripting? I'll try porting some parts of my Java code to JavaScript and see what happens. Stay tuned :)

Update:
Oh, and, by the way, I don't give a damn about static typing and compile-time type checking, at least when my team is composed by exactly one person: me. I agree that static typing can avoid a lot of trouble when there's a huge team of people cranking out code, but that's not my case here. So, more power to scripted languages... I'm wondering... will I be able to code my Java system in DreamWeaver some day? :)

Read: More on Extreme AOP

Topic: A Blog, At Last Previous Topic   Next Topic Topic: The Unexpected Answer to Java's

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use