Traits are a good feature but they are localized to the class that
does the extending.
AspectJ is still useful for targeting a whole set of classes, say in
the same package
or marked with an annotation. What would be great is if the aspect
could then add the
mixin scala-style using the trait api - but that would require
"AspectS" as mentioned
by Miles.
Besides AspectJ can do a lot more than simulate mixin behavior.
Personally I
think there will always be room for aspectj in any of the jvm
languages because
of its close and honest proximity to the bytecode and because it
provides a way
of encapsulating otherwise scattered host language constructs whatever
they
might be.
Maybe we need AspectJVM, AspectJ, AspectS, AspectG and AspectC - the
last one being for clojure - although It would be interesting to see a
jvm language
absorb an aspectj flavor directly into its compiler.
On 23 Jul 2009, at 08:31, Tahir Akhtar wrote:
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."
http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html
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 <[email protected]>
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
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
