Comments on: Status Update — A Fresh Look at Callbacks

By: Katz Got Your Tongue? » Callbacks, Redux

Katz Got Your Tongue? » Callbacks, Redux — Mon, 26 Jan 2009 06:49:02 +0000

[...] the end of last week, I continued my work on callbacks, which was actually pretty interesting. The initial approach, if you recall, compiled before, around, and after callbacks, with conditions, into a method that [...]

By: Bob Aman

Bob Aman — Mon, 19 Jan 2009 14:53:34 +0000

Any chance this speedup can be introduced to ActiveRecord, specifically after_initialize and after_find? Both of those are just unbelievably poor performers.

By: Weekly Digest, 1-18-09 - almost effortless

Weekly Digest, 1-18-09 - almost effortless — Sun, 18 Jan 2009 19:14:37 +0000

[...] A Fresh Look at Callbacks The entire Rails request cycle is around 4ms. This may have shaved off 1/2ms, which isn’t going to be that big a deal for any app, but like I said, a few more of these optz and the full Rails request cycle will moot Metal. [...]

By: wycats

wycats — Sat, 17 Jan 2009 19:09:52 +0000

Gaspard: This initial refactoring uses fairly opaque names for everything, because it was convenient that way. Once everything works with all the various callbacks in the system, I plan to go back and figure out how to make it easier to follow (by using much better names and also making it possible to see the output).

By: Andrei

Andrei — Sat, 17 Jan 2009 13:47:47 +0000

Nice insight into the refactoring process :)

On a side note, in ‘_run_hookz’, shouldn’t the ‘baz’ after yielding be ‘bar’ ?

By: Gaspard Bucher

Gaspard Bucher — Sat, 17 Jan 2009 09:55:31 +0000

A side effect of this might be to even more obfuscate debugging sadly. Walking through the callback chain has always been a pain, but now we’ll have one more opaque “eval”.

Maybe a solution could be to store the string for the method (http://github.com/wycats/rails/commit/95799d8f704db186c518330c386627ed726e1ab7#L2R104) when debugging so that it can be printed out.

By: Ennuyer.net » Blog Archive » 2009-01-16 - Today’s Ruby/Rails Reading

Ennuyer.net » Blog Archive » 2009-01-16 - Today’s Ruby/Rails Reading — Fri, 16 Jan 2009 17:05:33 +0000

[...] Status Update — A Fresh Look at Callbacks [...]

By: wycats

wycats — Fri, 16 Jan 2009 16:21:38 +0000

@antares trader: the Extlib version doesn’t support around filters or conditionals.

By: Antares Trader

Antares Trader — Fri, 16 Jan 2009 16:20:21 +0000

I recently got under-the-hood with Extlib::Hook. It does a very similar thing, I think, to what you discribe. It turns blocks into methods, then rewrites the filtered method to call the filter methods in-line. What is different in what you have done?

I know that DataMapper uses Extlib for for its filters, because it was a bug from datamapper that I was trying to solve. Doesn’t Merb use the same library for its filters?

Do you have any sense of how the Extlib version might compare to what you have done?

Thanks again for all the work!

By: aleco

aleco — Fri, 16 Jan 2009 15:59:02 +0000

okay, this might sound like a stupid question, but as I’m a novice I dare to ask: will we be able to use before/after/around_filters for ActiveRecord::Base classes too? More than once I was desperately searching for solutions to use before filters for various getters and setters, including collections (e.g. triggering a complex calculation when either the items in a collection of an object or various attributes are changed) – aka something other than the current AR callbacks such as before_save.

Oh, and yes, I know there are association callbacks, but they are very limited (as e.g. there’s no way to call a method only once no matter how many objects you’ve added and removed from the association).