On Mar 3, 2011, at 8:26 PM, Ryan Davis wrote: > Working on the installer and Gem.activate on 1.6 showed how crufty and > painful Gem, Specification and Dependency were. 1.7 is going to focus almost > entirely on refactoring the API into something useful. Specifically: > > + GemPathSearcher needs to die. God I hate it. 100% of it is bad design and > equivalent functionality should be built into specifications themselves. > + The relationship between Specification and Dependency needs to be made more > usable. In particular, going to source_index every time you need something is > an abomination. Specification should be able to respond with all specs that > match it's dependencies. > + Installer code and activation code needs a refactoring. The fact that I had > to do _nearly_ the same thing twice was proof of that. > + Gem.activate should be moved to Specification#activate. > + Gem.source_index should be hidden as an implementation detail (or removed) > and proper public counterparts should be added (eg. > Specification.all/active/find/named). > + Lots more Gem class methods should be moved to where their responsibilities > properly belong. There is so many LoD violations that it isn't funny. > > I'm sure there is a lot more. That's just off the top of my head. > > IMPORTANT: This release is going to be a code contraction month. Feature > additions / enhancements should NOT go in master and should NOT be released > in 1.7. We can add toys in 1.8.
Ryan, I have some change proposals which will probably impact this rather significantly that I've been toying around with, e.g.: https://gist.github.com/22fa600b8c98bdf8c785 It seems like implementing this would cover a lot of similar ground in spots. Is there a chance we can talk about how this fits in (or if it does at all) at some point? I was going to be drumming up a patch this weekend to integrate it for your guys' review, per a conversation with Eric and Evan. -Erik _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
