[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
AW: AW: [aspectj-users] Spacewar example
|
Hi Sian,
it could have helped
:)
unfortunately, in the solution you propose, you talk about something I just haven't got: in the Preferences, as I select Java ->
Editor, I don't get any tab named 'Problem Indication', but instead, some others more classical
: 'Appearance', 'Syntax', 'Typing', etc.
what's wrong
?
dragan
Hi
Dragan,
Please see AJDT bug 24064
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=24064) for details on #1.
In essence the Java eager parser is used for all .java files whichever
editor they are opened in. There are no problems in the tasks view because
all files are actually compiled with the AspectJ compiler, which recognises
these things.
Hope this helps,
Sian
Hi Ron,
Thanks for your answer.
Well,
To #1, I still
have errors in my editor, even after having turned on
aspectJ/java the editor
as default to java files.
To #2, it's a subjective question whether inner
aspects help modularity
or not. Personnally, I would try to separe both in
any case... But maybe
I'll change my mind as I aquire more experience on
it...
To #3, I was awaiting a code which the aspect compiler accepts,
and
where private fields could be accessed. But, maybe there is no way
?
-------------------------------------------------
Hi
Dragan,
Re: #1, check to make sure that AspectJ is the default editor for
.java
file
extensions (window | preferences | file associations). Using
.aj as the
extension for AspectJ source is now preferred, but Spacewar
predates
that.
Re: #2, sometimes a (static) inner aspect is a good
choice. If some
concern
crosscuts just a single class, or a general aspect
is applied to just a
single class, it can be quite helpful. Ramnivas wrote
some good articles
on
TheServerSide about refactoring with AOP that are a
good illustration.
Another common use case is in applying virtual mock
objects for testing
to a
specific test case. And in the space war code,
take a look and ask
whether
the inner aspects are helping modularity or
not. Aspects are a
modularity
technology, they aren't always oblivious,
i.e., you can write a system
where
the base code is aware of and interacts
with aspects and you can also
write
one where the aspects implement core
functionality that is required.
Re: #3, often you will want to do some
refactoring to address this. You
might find that some of the members apply to
the crosscutting concern
and
should be inter-type declarations. In a last
resort, you can make an
aspect
privileged to do exactly what you asked,
but that's usually not
the
right
answer.
-------------------------------------------------
Hello,
I
am pretty new in your community, so please don't be too hard to me if
I say
something wrong, or if there is something you've
already
discussed...
Looking at the spacewar game sample code, I was
surprised to see that :
1/ in my IDE (eclipse 3.0, ajdt1.1.2), the java
editor doesn't recognize
aspect keywords, if they are used in a class file
(eventhough, there
is no error shown in the tasks list)
2/ there are
inner aspects declared in java classes ! That's shocking.
My understanding of
the AOP philosophy, was that aspects are separated
from a java project; they
should only describe an additional "aspect" of
the project; they should not
make the code unclear, etc.
3/ as I tried to separate myself aspects from
java classes, I got the
problem that my aspects can not access private fields
declared in the
aim class; is there any way to solve that
?
Regards,
Dragan
_______________________________________________