When I was reading "scala as long term replacement", following para
caught my eyes:
"Scala also has proper mixins (traits) so you don't have to muck about
with AOP wackiness to get nice modular code."
Being totally new to Scala at first I took it as "Scala doesn't need
AOP at all".
This thread made me go back to the blog post, now I understand that he
was just referring to mixins and other features of AOP like advices
were not subject of this comment.
Am I right?
Regards
Tahir Akhtar
Dave Whittaker wrote:
I'm not saying I'd advocate switching focus from Groovy to
Scala, but for what it's
worth the thing that got me interested was that Groovy's creator, James
Strachan, blogged about Scala recently and said: "I can honestly say if
someone had shown me the Programming in Scala book by by Martin
Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have
never created Groovy."
I
looked through the tour last week and it does seem awfully cool......
On Jul 22, 2009, at 4:48 PM, Ashley Williams wrote:
So the scala team would have to get up to speed with the
pointcut parser and coordinate with the aspectj team.
That's assuming they are already familiar enough with aspectj
already. And then put some sort of implementation
together and go through many test and release iterations.
Whilst all the time attending to main scala issues.
Given that I don't even see much interest in pursuing this, it
looks scala users will need to be familiar with the source
transformations for a long time to come in order to use
aspectj. Unless you suddenly switch from Groovy to Scala, Andy ;-)
On 22 Jul 2009, at 17:59, Andy Clement wrote:
The AspectJ pointcut parser is a reusable
component (used in Spring Framework, for example). However, it does
have a well defined set of join points which may or may not make sense
in the context of another language (most likely more would be needed
too).
The AspectJ pointcut matcher is a reusable component. If you can
conjure up something that looks like a join point (using whatever means
you like), it will tell you whether a pointcut matches that and what
any required runtime test would be. The AspectJ weaver is an example
of something that consumes bytecode and presents pieces of it as
candidates to the pointcut matcher. We are progressing with also
implementing a Eclipse JDT source level system that would allow AspectJ
pointcuts to be matched against Java source (so matching without the
need for compilation).
Personally I'm spending more time with Groovy right now than Scala.
However, in both cases AspectJ will have issues with the compiled
code. We already have an open bug about being unable to weave Scala
code and I know that groovy code does a huge amount of transformation
to produce its class files so when AspectJ would be looking for join
points, they would be very hard to pick out. I would estimate it is a
large amount of work to get weaving and the semantics of that weaving
consistent across these languages.
Andy
2009/7/20 Ashley Williams <ashpublic@xxxxxxx>
I second that question. Am I right though in
thinking that AspectJ is really about targeting join points
at the byte code level? If this is remains true - and I
can't see how it would be practical to change this -
then you'd always have to be aware of how the scala source
code for example gets de-sugared.
I'd be very interested in tighter integration between
scala and AspectJ.
- Ashley
On 20 Jul 2009, at 14:02, Michael McCray wrote:
Hi All,
I was wondering if it is required that AspectJ is tied to the Java
Language? I see that is what the J is for, but there are some new
languages like JavaFX and Scala that I don't think have supporting
aspect extension languages. There is http://functionaljava.org/,
a variant of Java that supports closures and other functional language
concepts. What if AspectJ could become AspectJVM and support other JVM
languages? I understand LTW can do much of what I ask, how far off is
LTW from a real integration? I mean it would be nice to write my
aspect code using other language features as well at least this would
not be possible until the aspectj language specification changed.
Why not add closures to AspectJ to support it's usage in aspects? How
is it decided to evolve the language?
Mike
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
|