From: Aredridel <aredridel@...>
Date: 2003-08-29T03:28:54+09:00
Subject: Re: Aspect oriented Everything?


--=-h3KkKiSjYwyeG3G/NPhJ
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

> It is only when you run into this kind of situations, that you start
> to think about code factorization in a different dimension.

Bingo, thank you, Hung Jung!  That makes AOP -totally- make sense to
me.  I realize I do it already, instinctually, usually with callbacks in
methods -- I'll pass self to a mixin method at the top of the method,
and perhaps later at the bottom, letting me use a ruby mixin as a sort
of kludgy AOP cutpoint.

> AOP is a really need. I would agree that it is still an immature field
> of research. But people really need it.

Definately.

I'd love to see Ruby's mixin concept extend around AOP -- it seems that
that's where some true power lies -- unifying the two dimensions back
into a single, multi-dimension tree structure.

I was postulating as I went to sleep last night that if you could have a
new sort of Mixin that could /wrap/ code instead of implementing the
base, that would be best -- and some syntactic sugar is most of what's
needed. The rest would just be a change in the order methods are
resolved: aspects first, then class implementation, then mixins and up
the tree.=20

Some hypothetical code:

class Foo
  include Bar    # Ordinary mixin
  aspect Baz
  aspect Grot    # "Wrap" mixin, where the code covers over
                 # existing methods, but has a keyword like "super"
                 # to easily call original implementation.

  def frob
    puts "In frob"
    super
  end =20
end

module Bar
  def frob
    puts "Bar frob!"
  end
end

module Baz
  def frob
    puts "Before frob 2"
    super
    puts "After frob 2"
  end
end

module Grot
  def frob
    puts "Before frob 1"
    super
    puts "After frob 1"
  end
end

Foo.new.frob

and the output would be:

Before frob 1
Before frob 2
In frob
Bar frob
After frob 2
After frob 1

All this would allow a very perlish-style feature of "change the input
instead of the algorithm if it's easier", but with a nice, modular and
abstract OO and Aspect-oriented way.

I can imagine a generic Tree class [and even more useful in a less
dynamic language] using aspects to handle the actual concrete types of
tree, but have the core class just know about a generic Tree concept...
that's just one tiny use that I can see now.

Ari

--=-h3KkKiSjYwyeG3G/NPhJ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQA/TknFtP09exA3hooRAhx0AJ4qqZ1+aMjrqRBji4anoE5ymu1aJgCggYln
ZQw0R/Q6gLah6dkaox7mItQ=
=sVyS
-----END PGP SIGNATURE-----

--=-h3KkKiSjYwyeG3G/NPhJ--