transfire at gmail.com
Mon Aug 27 11:31:20 EDT 2007
On Aug 25, 7:04 pm, Trans <transf... at gmail.com> wrote:
> On Aug 25, 12:55 pm, Trans <transf... at gmail.com> wrote:
> > On Aug 25, 11:01 am, "George Moschovitis"
> > <george.moschovi... at gmail.com> wrote:
> > > > The difficulty comes when the methods do not already exist.
> > > yeap, this is the problem. My version (included in the repository code)
> > > handles this
> > > my using a mandatory call to Aspects.setup after all dynamic methods are
> > > defined.
> > > But I think there are still some bugs (for example on bug reported earlier
> > > in this week).
> > You're using this for Og models, right? Are you using it for Nitro
> > controllers too? Anywhere else?
> > I don't 100% understand the design btw. Could you explain
> > what :on, :where, :only, :except, and :join options do?
> > > I tried to use the version from facets but I had some problems. Tomorrow I
> > > will review
> > > my version and the code from facets, and I will be in better position to
> > > help you with this.
> > > > method_missing. (Basically imagine every method call being routed via
> > > > method_missing).
> > > this sounds *awfull* to me!
> > He he. Well, it's not *that* bad! The nice things is that it's 100%
> > dynamic. No fuss with included or method_added, which can be easy to
> > break.
> > In any case, for the time being it's probably best just to fix and
> > improve your lib. It doesn't needs to be an all or nothing affair. I
> > think there's room for both approaches in the library. I can add mine
> > as a separate lib, and over time we can see how they fair/work
> > together/cross-pollinate/etc.
> > I have to go now, but let compare notes tomorrow.
> I thought about this some more and I think you are right that dynamic
> dispatch, as I suggested it, is too inefficient in itself. But I
> realized that it would be possible to add an advice cache, and trigger
> the appropriate parts of the cache be recalculated when certain
> changes occur (method added, aspect added, etc). So then it would be
> quite efficient, in fact it amounts effectively that same basic design
> as yours.
> There's also another part of this. I have a joinpoint model I really
> like, which is completely flexible. I'd like to use that, and then
> layer your pre, post, around methods on top of that. I pretty
> confident that would be a great design. And the we can have one lib
> that satisfies us both.
Reconsidered. My cut based AOP is looking good. But I think pre, post
and around method filters don't need to be strapped to such a "major"
AOP system. So I'd like to focus on your lib. Do you have any time to
work on this today, George?
More information about the Nitro-general