Which problem is it solving for you ? Do you see any performance gains that I'm missing ? Do you believe if this is making any code easier to understand ? Could you please provide failing tests which are to be fixed by the refactoring in question ?
Thanks. On Wed, Apr 22, 2009 at 6:15 PM, DWF <[email protected]> wrote: > > Given that the GSOC Rails projects involve some ActiveRecord > refactorings, doesn't this type of improvement make sense? > > --dwf > > On Mar 8, 12:42 pm, Niels Ganser <[email protected]> wrote: >> I realize us Rubyists don't necessarily think the classic works in the >> field such as Fowler's "Refactoring" apply to our day-to-day coding in >> their entirety but in this case I fully agree with Fowler when he says >> "You don't decide to refactor, you refactor because you want to do >> something else, and refactoring helps you do that other thing". >> >> I myself have had my faire share of frustration when browsing around in >> the AR associations code and as anyone who has ever done more than a few >> hours of programming knows confusion always – and I mean always! – leads >> not only to more bugs but also hinders in adding features to the >> confusing code. >> >> I'd argue those "odd bugs"Adam mentioned have already been there. Many >> times. There is no *one* bug that shouts "I'm here because this code >> needs to be refactored!", it usually is much more subtle than this. >> Years of experience generally show though that the harder code is to >> understand, the more buggy it will be. >> >> Now *if* there is fantastic test coverage and *if* someone is willing >> and able (regarding skills and free time) to give it a shot, I say go >> for it: Fork, refactor, push, and show us! >> >> IMHO there's never a better time to refactor than right *now*. Besides >> yesterday of course.. >> >> Best, >> Niels >> >> Pratik wrote: >> >> More importantly, the added complexity created by importing all of the >> >> collection logic and interface into a non-collection association class >> >> just adds to rigidity and potential for odd bugs in the future. >> >> > Let's do this refactoring when that actually happens. >> >> >> What concerns me most about this is that resistance to cleaning up >> >> code likely implies a lack of confidence in the test suite. >> >> Considering how core associations are to Rails, and the not >> >> insignificant amount of cruft in that code, there should be tests on >> >> associations like fat kids on an ice cream truck. What are you >> >> concerned the changes will break, given that all the tests pass? >> >> > There is no lack of confidence. But I'm not very much in favour of >> > refactoring without any performance gains or any obscure bug fixes. >> > Refactoring like these makes almost all the relevant patches in LH >> > stale and screws up the history. I just don't think the patch in >> > question here is worth that. > > > > -- Cheers! - Pratik http://m.onkey.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
