On 8/20/07, Luke Redpath <[EMAIL PROTECTED]> wrote: > > This looks like a definite improvement. Cleaner separation of > concerns, easier to extend and probably far easier to test. +1 > > Courtenay wrote: > > Hi guys, what do you think about this implementation (before I go off > > and actually make it work). The plan is to make it easier to write > > extensions or plugins for find, as well as define your own options for > > the precious first-level argument, :first, :all, etc. >
Beyond sharing the option-santizing methods, why is find(:first, ...), find(:all, ...) preferable to find_first and find_all? As this patch highlights, utilising the first argument like this makes it more difficult to add new behaviour, but adding another dispatch layer to lengthen the stack trace might be tackling the wrong problem to reach the goal of making AR's internals easier to enhance. The patched code is definitely nice, and definitely makes it simpler to add new behaviour to the find() method. However, it also seems like a lot of hoop-jumping to preserve a customised method-dispatch mechanism, when it might be more sensible in the long term to figure out a better way for concrete methods (find_first, find_all, find_with_some_other_behaviour) to work with the option wrangling code. -- * J * ~ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
