Having just spent a lot of time wading through the HMT and HOT code, I'll agree that there is a lot of room for improvement w.r.t. clarity. And if there is a general agreement that a refactoring is needed then the longer we wait the tougher the job will be. I would encourage Adam's effort.
However, having already had discussions with several of you in the past, I think we all know the problem doesn't stop with HMT and HOT - it's the entire inheritance hierarchy and mixin structure of associations. So Adam, are you prepared to expand the scope of your refactoring to tackle the bigger job? Because I can see some downside to a partial refactoring that leaves a code base with no track record and few acolytes. Then finishing the job could actually be harder. But overall, I think the clock is ticking on this one. Associations code is already big and complex. Every accepted patch just adds to the inertia of the current structure that I think everyone knows needs to be re-thought. --Chris On Apr 22, 4:28 pm, Chad Woolley <[email protected]> wrote: > On Wed, Apr 22, 2009 at 10:51 AM, Pratik <[email protected]> wrote: > > > 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 ? > > I believe that Adam already addresses many of these points in his original > post: > > "This inheritance relationship has already caused its share of bugs, as > mentioned by commenters on the ticket. I fixed two > here:http://rails.lighthouseapp.com/projects/8994/tickets/895-has_one-thro.... > 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." > > It is hard to write a failing test for bugs that don't exist, but the > existence of prior already-fixed bugs should be considered as a > motivation for doing the refactor. > > Furthermore, the existence of bugs isn't normally the primary > motivation for refactoring - but they are a symptom of a needed > refactoring. Complex, hard-to-understand code is a direct motivation > for refactoring, which I think is the point here. > > -- Chad --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
