transfire at gmail.com
Sat Aug 25 22:04:23 EDT 2007
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
> 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
> 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
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.
More information about the Nitro-general