Aaron Sherman sent the following bits through the ether:
> It is not. That's exactly the point to AOP, to bring the two
May I suggest that all discussion move to the perl-aspects list
and that everyone take a look at the Aspect module on CPAN.
The language does not need to be changed t
d"
> > delcaration only on the foriegn class in C++. It simply should not
> > work that way.
>
> I have no objection to requiring a "friend" property for access to
> hidden data; or to allow addition of before and after methods.
> That's an orthogonal i
You have seen Aspect.pm haven't you? Aspect Oriented Programming for
Perl 5, built on top of Hook::LexWrap and very, very cool.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
tionship, there are 3 places where it can potentially be
formalized: the source, the target or an indirection table. Any of
these possibilities may be correct, in a given situation. Perl
isn't an RDB, so we aren't forced to formalize at the M end of an M:1.
> AOP is intended as a des
houghts
>
> I do like the idea of AOP; but I think the mechanism you suggest
> are too clumsy. The particular weave that you are attempting is to
> add before- and after- functions to a set of existing functions.
> Ideally, this shold be imposed on the functions from outside.
>
Aaron Sherman wrote:
> All of this is still coming into focus for me, and I want to spend
> more time reading the articles later, but for now I just wanted
> to see if anyone else has been thinking these thoughts
I do like the idea of AOP; but I think the mechanism you suggest
are t
In reading the Oct'01 issue of Communications of the ACM, I find myself
intrigued by the concept of aspect oriented programming (AOP). The basic
idea is that some methods in an object tree have simillar concerns even
though they are in different objects. AOP is an attempt to make
