[rspec-devel] christmas cleaning

Brian Takita brian.takita at gmail.com
Tue Dec 11 12:46:43 EST 2007


On Dec 1, 2007 7:52 AM, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>
> On Dec 1, 2007 4:07 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On Dec 1, 2007 8:06 AM, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > hi all,
> > >
> > > we've all been cleaning up and deleting crufty code lately - good!
> > >
> > > i'd like to continue this so we get a leaner and faster codebase. suggestions:
> > >
> > > 1) Options
> > > It has too many references to various things. I'd like to make it know
> > > less and move the references to the objects that use them instead of
> > > asking options
> >
> > +1
> >
> > > 2) Reporter
> > > It's an unnecessary middleman. The classes talking to it should talk
> > > directly with the formatters instead and we should delete Reporter.
> > > Instead of getting options through the constructor it's cleaner to
> > > pass an array of formatters to the various run/execute methods.
> >
> > +1
> >
> > This is how the Story Runner already works. It lets you register
> > listeners. The ones it uses ignore everything they're not interested
> > in w/ method_missing.
> >
> > I wonder if we can have a single html formatter that serves both
> > stories and examples. Especially now that we have nested example
> > groups.
> >
> > >
> > > 3) Example
> > > I'd like to merge this class with ExampleMethods and get rid of
> > > Example. This requires some changes in SharedExampleGroup.
> >
> > +1
> >
> > We've discussed this off-line, so to fill everyone else in ... we now
> > have two concepts for sharing: nested example groups and shared
> > example groups. The difference is that shared groups share
> > before/after, helper methods and examples, whereas nested groups share
> > everything but the examples.
> >
> > If we define methods instead of storing examples, we can simply
> > inherit everything and pass down a lists of methods to run and not to
> > run. This would align these mechanisms and simplify things a great
> > deal.
> >
> > We started in this direction but discovered that auto-generated
> > example docstrings didn't work any more (e.g. specify {foo.should ==
> > bar ). I have an idea of how we can solve that (other than removing
> > the feature :) )
> >
> > > 4) Lazy loading
> > > In order to run faster we should require files as needed. We don't
> > > need to load all the formatters. There may be other classes too.
> >
> > +1
> >
>
> The story framework is no longer loaded by require 'spec' - it has to
> be loaded explicitly with require 'spec/story'.
> Further - formatters are loaded lazily and transparently.
>
> This had a huge impact on the startup time :-)
Thats really surprising. Any ideas why just loading the story files
and the formatters is so slow?

One may argue thats its just simpler if everything is required. I
don't know if its desirable or worth it, though.
>
> Aslak
>
>
> > >
> > > 5) Move circularly dependent classes in expectations and matchers into
> > > one directory.
> >
> > -1
> >
> > Circular dependencies are a problem in things that get deployed as
> > separate packages, not just because they're in separate directories. I
> > don't think this is a problem here. And it's nice to have things
> > separated. Merging these would buy us nothing and add confusion, IMHO.
> >
> > >
> > > These are the things off the top of my head. Thoughts?
> > >
> > > Aslak
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>


More information about the rspec-devel mailing list