From: Olivier Nenert <olivier@...>
Date: 2003-08-29T03:59:18+09:00
Subject: Re: Aspect oriented Everything?

For what I understood so far around what aspect oriented programming would 
try to solve,
it seems that passing blocks that you can yield and reflexion already works 
around
those problems. I was thinking about a neat addition that would maybe offer 
another solution
to he idea of "defining eternaly" some of the methods that should behave 
according to a pattern,
We already have public, protected and private methods,
why not adding a syntax which would allow us to mark a method (even putting 
it several marks)
public, protected or  private would just be a particular property that has 
been assigned to a method.
so you could create your own marks and stating with according syntax, say 
:?private or :? (empty to unmark)
or in this case :?red (where you define in a mixing how to reshape red or 
blue methods so as to factor code) etc..
with this mark available in reflexion, the object at instanciation time (or 
mixing inclusion time,
or whenever would be the best) could be aproprietely redifned including the 
opening and closing blocks of code,
or doing pretty much anything (this could surely be useful to some other 
concepts than just aop)
for instance, you could define a sandbox mixin which treats the methods 
marked as dangerous (or tainted)
in a special way, or you could have a debug or profile mixin that would 
monitor or output the results of apropriately 'marked' methods .
Oh well, it's just an idea, not a feature request :)
(but I do think it would be nice, particularily if this mark syntax gets 
elaborated enough to have parameters and even blocks)

cheers..

Olivier.


> 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.
>
> 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  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
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/