c*****a
发帖数: 15 | 1 AOP: Aspect-Oriented Programming?
What do you think about it?
Have you used it in your project?
What is your experience in using a AOP implementation such as AspectJ?
What are the reasons behind your conclusion? | e***g
发帖数: 158 | 2 funny you ask, sombody just releases yet another AOP framework today
http://www.theserverside.com/news/thread.jsp?thread_id=23902
【在 c*****a 的大作中提到】
: AOP: Aspect-Oriented Programming?
: What do you think about it?
: Have you used it in your project?
: What is your experience in using a AOP implementation such as AspectJ?
: What are the reasons behind your conclusion?
| p***n
发帖数: 635 | 3 another hype?
【在 c*****a 的大作中提到】
: AOP: Aspect-Oriented Programming?
: What do you think about it?
: Have you used it in your project?
: What is your experience in using a AOP implementation such as AspectJ?
: What are the reasons behind your conclusion?
| c*****a
发帖数: 15 | 4 That is the cause I ask this question. :) I am looking at this new framework
and try to figure out if this is a better way to do AOP.
The AspectJ is the most popular impementation. however you have to insert the
aspect declaration (which is a totally new language independent of Java) into
your java source file, and use their special compiler to compile.
It is quite powerful to do some helping tasks with AspectJ such as logging
etc, I only wonder if it is worthwhile to do that in such a extreme w
【在 e***g 的大作中提到】
: funny you ask, sombody just releases yet another AOP framework today
: http://www.theserverside.com/news/thread.jsp?thread_id=23902
| e***g
发帖数: 158 | 5 I think the issue is not how to do AOP, but what kind of problems need AOP.
this is a time of confusion, with many new(?) architecture styles under
examination and nobody knows how to assemble them into harmony yet. in this
mess it's unclear about where is the position of AOP in the big picture.
practically, at this point, if an AOP framework is powerful, it will be
too extreme for production software (too much risk to use non-standard
language or runtime); if it's more tranditional like dynaop,
【在 c*****a 的大作中提到】
: That is the cause I ask this question. :) I am looking at this new framework
: and try to figure out if this is a better way to do AOP.
: The AspectJ is the most popular impementation. however you have to insert the
: aspect declaration (which is a totally new language independent of Java) into
: your java source file, and use their special compiler to compile.
: It is quite powerful to do some helping tasks with AspectJ such as logging
: etc, I only wonder if it is worthwhile to do that in such a extreme w
| c*****a
发帖数: 15 | 6 I don't think AOP should hide from "normal" programmers, it gives you some
powerful features which I think will be added into Java language itself in the
future.
The extreme way is not necessarily the powerful way. IMHO, the AspectJ team
has a Academic background and they chose to have a cool new language. It has a
good academic reason, however, produces headaches for programmers who do the
really work. And they are limited to their pure language experience, the
AspectJ is good when you just pla
【在 e***g 的大作中提到】
: I think the issue is not how to do AOP, but what kind of problems need AOP.
: this is a time of confusion, with many new(?) architecture styles under
: examination and nobody knows how to assemble them into harmony yet. in this
: mess it's unclear about where is the position of AOP in the big picture.
: practically, at this point, if an AOP framework is powerful, it will be
: too extreme for production software (too much risk to use non-standard
: language or runtime); if it's more tranditional like dynaop,
| e***g
发帖数: 158 | 7 i'm a little worried that java language is becoming too complicated.
it's very hard to know what is essential, sun is reluctant to add new things.
generic java had existed for many years, it only goes to standard language
because of microsoft's theat. aspectJ is unlikely to have that chance.
by architects I refer to those senior developers in a project team who does
more infrastructure works than normal chors.
【在 c*****a 的大作中提到】
: I don't think AOP should hide from "normal" programmers, it gives you some
: powerful features which I think will be added into Java language itself in the
: future.
: The extreme way is not necessarily the powerful way. IMHO, the AspectJ team
: has a Academic background and they chose to have a cool new language. It has a
: good academic reason, however, produces headaches for programmers who do the
: really work. And they are limited to their pure language experience, the
: AspectJ is good when you just pla
| m******t
发帖数: 2416 | 8
That's exactly my impression on JDK 1.5. Java is losing its elegance
as a language - I mean, come on, varargs? it's like hijacking us
back to C...
【在 e***g 的大作中提到】
: i'm a little worried that java language is becoming too complicated.
: it's very hard to know what is essential, sun is reluctant to add new things.
: generic java had existed for many years, it only goes to standard language
: because of microsoft's theat. aspectJ is unlikely to have that chance.
: by architects I refer to those senior developers in a project team who does
: more infrastructure works than normal chors.
| e***g
发帖数: 158 | 9 I actually like varargs or new for. I do have many new Object[]{}
or for(Iterator..) messing my codes.
but System.out.printf()..... we all come from C era and knows how
to write and read that, but new kids are screwed, hehe
【在 m******t 的大作中提到】
:
: That's exactly my impression on JDK 1.5. Java is losing its elegance
: as a language - I mean, come on, varargs? it's like hijacking us
: back to C...
| m******t
发帖数: 2416 | 10
Is the whole "String s=(String)iterator.getNext()" business
cumbersome? sure. Is it worth it to make the langauge more
complicated just to deal with that? probably not.
【在 e***g 的大作中提到】
: I actually like varargs or new for. I do have many new Object[]{}
: or for(Iterator..) messing my codes.
: but System.out.printf()..... we all come from C era and knows how
: to write and read that, but new kids are screwed, hehe
| e***g
发帖数: 158 | 11 well you probably don't do coding a lot. i heard ppl worrying about
generics, static imports, but you are the first one opposing the
'enhanced loop'. this is a very trvial and straightforward syntax
sugar, it's so isolated and doesn't incurr wide-spread complexity
(auto-boxing is 10X, enum is 100X complicated, generics 1,000,000X)
and it indeeds simplifies a very commonly used part of language,
and welcomed almost unanimously (minus you:)
but syntax sugar is always a matter of taste, and who kno
【在 m******t 的大作中提到】
:
: Is the whole "String s=(String)iterator.getNext()" business
: cumbersome? sure. Is it worth it to make the langauge more
: complicated just to deal with that? probably not.
| c*****a
发帖数: 15 | 12 I don't think those syntax sugar are any real benefits either. how often a
couple of more lines of typing is a serious problem for your productivity? On
the contrary, I would start to worry if programmers code too fast.
However, I will blame Microsoft for this. They always show off those eye
candies and try to prove the C# is better. I think Sun is dragged into this
war of features.
【在 e***g 的大作中提到】
: well you probably don't do coding a lot. i heard ppl worrying about
: generics, static imports, but you are the first one opposing the
: 'enhanced loop'. this is a very trvial and straightforward syntax
: sugar, it's so isolated and doesn't incurr wide-spread complexity
: (auto-boxing is 10X, enum is 100X complicated, generics 1,000,000X)
: and it indeeds simplifies a very commonly used part of language,
: and welcomed almost unanimously (minus you:)
: but syntax sugar is always a matter of taste, and who kno
| m******t
发帖数: 2416 | 13 uh, embug, want to reconsider your "unanimously" statement? 8-)
【在 c*****a 的大作中提到】
: I don't think those syntax sugar are any real benefits either. how often a
: couple of more lines of typing is a serious problem for your productivity? On
: the contrary, I would start to worry if programmers code too fast.
: However, I will blame Microsoft for this. They always show off those eye
: candies and try to prove the C# is better. I think Sun is dragged into this
: war of features.
|
|
