On Wed, Oct 24, 2001 at 11:50:05AM -0700, David Whipp wrote:
> > If Perl is going to have data hiding (I think I read that this was a
> > goal), then you cannot declare these relationships outside of the
> > class that defines the method. That would be like putting a "friend"
> > 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 issue.
It is not. That's exactly the point to AOP, to bring the two
together to allow higher level descriptions of cross-class
"concerns" (I hate that word in this context).
By allowing external code to execute within your method, with
privaleged access to its data, you imrpove modularity and
ease of design. You no longer have to make an entire class
"special", only the one function that needs to act on your
behalf, and you tell it when to act.
> > Your suggestion also has the dubios honor of being a "come
> > from", which while amusing in Intercal, is probably not
> > desirable in Perl ;-)
>
> I'm sorry, I don't know Intercal.
Intercal was a joke. It attempts to make programming as painful
as possible. By providing a "come from" syntax (introduced by
ESR, I think), it made it impossible to to tell what a given
section of code would do.
Take for example:
use stuff;
class X;
# ...
sub .Y () { return 1; }
package main;
X.new().Y;
Given what you suggest, I cannot predict what this code will do,
because stuff might (and would be "correct" in doing so) inject actions
to be performed inside of X.Y
> > AOP is intended as a design tool, not necessarily a code reuse
> > tool.
>
> I'm not sure that I like to make that distinction. One of the goals
> of OO design (even using AOP) is to minimize redundancy.
Why would the distinction eliminate the goal? AOP is something that
really comes into play in object construction, not re-use. You can
re-use AOP-friendly objects, but I don't know that it even makes
sense to discuss AOP "at re-use time", unlike, e.g., inheritance.
Mathematical functions are not code re-use tools either....
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs 6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
"Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew." -Queen/_'39_
