From: Alexandru Popescu <the.mindstorm.mailinglist@...>
Date: 2005-09-15T19:55:56+09:00
Subject: Re: ruby and aop

#: Trans changed the world a bit at a time by saying on  9/15/2005 12:36 PM :#

Firstly many thanks for taking the time to answer. Than more questions inlined :-)

> Hi Alexandru,
> 
> Well, in my experience the hardest part has been dealing with name
> clashes between advice and the methods they effect, though I think that
> is exhaserbated with the approach we've taken (which I suspect you've
> read).
> 

which one are you refering to?

> Another difficulty with what I think you have in mind, is actually
> tapping into those joinpoints. You will likely be needing to modify
> core --which isn't very condusive to adoption.
> 

by modifying the core you mean to alter/add the Object, Module, etc functionality; or something more 
  deeper? indeed I might need at some moment to open/alter Object, Module, etc, but I would like to 
stay at that level.

my (possible) naive thoughts are in the following direction:

- assure that aspects definitions are loaded always first, so that I can have a centralized place to 
control pointcuts
- using inspection code I can plug hooks on the joinpoints matching pointcuts loaded in the first place
- using inspection code I can do mixins too

Probably the most interesting thing from this perspective (I feel that I should underline this 
again: maybe naive) is how many joinpoints I will be able to watch based on existing inspection code 
(I think one of the documents I have read already analysed this part).

- a more difficult part is the aspect instanciation model; well for the moment I haven't gonne so 
far to imagine what would mean aspects with perthis, pertarget, perX;

- another interesting part will be the cflow/cflowbelow;

but as I usually like to start small and afterwards grow I would be happy to have at least the first 
part done.

> Really the thing about Ruby is that it already offers a lot of
> AOP-esque features, albiet they are a bit scatted about. Hooks and
> callbacks go along way toward serving as joinpoints (though there are a
> few notably missing). Method aliasing serves as a workable, albiet
> slightly clumsy due to potential name cashes, means of advice. And
> ObjectSpace.each_object allows one to tap into every part of the
> system; certainly not the most efficient, but generally effective since
> the costs are typically all up front.
> 
> T.
> 
> 
> 
Surely, there are lots of hacks that can be done and get a feeling of doing aop (I don't want to 
sound harsh). However, in bigger systems and for ease of solution they are not the silver bullet 
(nor the aop is :-)).

please let me know what do you think,
:alex |.::the_mindstorm::.|