Check out http://www.aspectJ.org . This is a Java-specific aspect-oriented
framework that is (arguably, depending on who you ask) the most advanced in
terms of functionality. Although the docs relate to this framework in
particular, they provide a coherent intro to the subject.
-----Original Message-----
From: Sam Roberts [mailto:sroberts@uniserve.com]
Sent: Wednesday, February 04, 2004 10:48 AM
To: ruby-talk@ruby-lang.org
Subject: what is aspect-oriented s/w? (was Re: role pattern lib for
ruby)
Is there a description of it somewhere?
aosd.net is singularly void of information, pointing only to an old ACM
issue thats not available online, and pdfs of academic research papers.
I keep hearing the term, but not associated with any concrete
information. All the projects I’ve seen just point to aosd.net, and
their docs assume you already know what aspect-oriented, cross-cutting,
etc., mean.
Can anybody help me out?
Cheers,
Sam
Quoteing shasckaw@skynet.be, on Thu, Feb 05, 2004 at 12:30:03AM +0900:
shasckaw wrote:
Thansk for the link, it looks interesting but it is perhaps too complex
for what I intend to do. But I can give it a try… well, I’d be happy
to try it but there isn’t any files in the package, and project activity
is near to death. I’ll try to get more info about it, but I haven’t much
hope.
Now, I know the truth, I had a bug with my archive manager that’s why I
couldn’t look into the package. I didn’t think it could be my archive
manager because I never had such problems before. I must tell the
package is a little weird, with the extension “tgz.gz” or “tgz.tar”.
Well, no matter all this, now I can use it and that’s a good new. BTW
the develloper of robjectteams told me he doesn’t use the CVS, so it’s
normal that it is empty.
I think I can give a reasonable overall picture of AOP.
Think about it from a top-down view-point, as a form of weaving code together,
as opposed to the traditional manner of building one block on top of another.
So lets say you want to monitor employees. So you create a model of an
employee, then you create a logging mechinism, and say a visualizer. AOP
allows you to weave these components together describing how they interact,
without requiring you to specifically modify any of the code within them.
Traditionally you would have built the logging mechinism on top of, or
integrated into, the employee model, and likewise with the visualizer. AOP
allows you to have much cleaner Seperations Of Concerns --and that’s the real
point of AOP.
So an aspect then, is one of these concerns, and is said to be orthogonal to
the other concerns. The weaving is accompished by describing where code is to
be “interwoven” into other code. The code that gets “inserted” is called advice (in practice it is defined much like one does a method). This is
accomplished by selecting join-points. Join-points are specific places in
code that can have other advice code inserted into it, and are selectable by
some descriptive syntax. This syntax will select a set of joint-points; a set
of join-points so selected is reffered to as a point-cut.
Date: Thu, 5 Feb 2004 11:16:42 +0900
From: T. Onoma transami@runbox.com
Newsgroups: comp.lang.ruby
Subject: Re: what is aspect-oriented s/w? (was Re: role pattern lib for
ru by)
I think I can give a reasonable overall picture of AOP.
Think about it from a top-down view-point, as a form of weaving code
together, as opposed to the traditional manner of building one block on top
of another. So lets say you want to monitor employees. So you create a
model of an employee, then you create a logging mechinism, and say a
visualizer. AOP allows you to weave these components together describing how
they interact, without requiring you to specifically modify any of the code
within them. Traditionally you would have built the logging mechinism on
top of, or integrated into, the employee model, and likewise with the
visualizer. AOP allows you to have much cleaner Seperations Of Concerns
–and that’s the real point of AOP.
So an aspect then, is one of these concerns, and is said to be orthogonal
to the other concerns. The weaving is accompished by describing where code
is to be “interwoven” into other code. The code that gets “inserted” is
called advice (in practice it is defined much like one does a method).
This is accomplished by selecting join-points. Join-points are specific
places in code that can have other advice code inserted into it, and are
selectable by some descriptive syntax. This syntax will select a set of
joint-points; a set of join-points so selected is reffered to as a point-cut.
HTH,
T.
–
ATTN: please update your address books with address below!
The difference between art and science is that science is what we
understand well enough to explain to a computer.
Art is everything else.
– Donald Knuth, “Discover”
/bin/sh -c ‘for l in ruby perl;do $l -e “print "\x3a\x2d\x29\x0a"”;done’
===============================================================================
I think I can give a reasonable overall picture of AOP.
[short AOP description]
HTH,
T.
I have already tried to understand AOP. The stuff I’ve already read
about it explained aproximatively the same things as you did. But I must
tell it doesn’t help me much to understand. Those concepts Join-Points,
Point-Cuts, advices, aspect and concerns are too blurred for me.
Someone has already proposed AOP for python and Guido Van Rossum himself
said him it was not its intention to do that as it is possible to do AOP
with the use of meta-classes.
Then I suppose it is possible to do that in ruby either. If some fair
people could give some simple examples of practical AOP in ruby, it
would probably help everybody to grasp the concepts.
Meanwhile I’ll try to get something from robjectteams.
Thanks, that does help a bit, though it still quite abstract. Its hard
to picture how a logging mech, employee, etc, would actually get woven
together, usefully.
I have to find some code, that will help.
Sam
Quoteing transami@runbox.com, on Thu, Feb 05, 2004 at 11:16:42AM +0900:
···
I think I can give a reasonable overall picture of AOP.
Think about it from a top-down view-point, as a form of weaving code together,
as opposed to the traditional manner of building one block on top of another.
So lets say you want to monitor employees. So you create a model of an
employee, then you create a logging mechinism, and say a visualizer. AOP
allows you to weave these components together describing how they interact,
without requiring you to specifically modify any of the code within them.
Traditionally you would have built the logging mechinism on top of, or
integrated into, the employee model, and likewise with the visualizer. AOP
allows you to have much cleaner Seperations Of Concerns --and that's the real
point of AOP.
So an *aspect* then, is one of these concerns, and is said to be orthogonal to
the other concerns. The weaving is accompished by describing where code is to
be "interwoven" into other code. The code that gets "inserted" is called
*advice* (in practice it is defined much like one does a method). This is
accomplished by selecting join-points. *Join-points* are specific places in
code that can have other advice code inserted into it, and are selectable by
some descriptive syntax. This syntax will select a set of joint-points; a set
of join-points so selected is reffered to as a *point-cut*.
