I agree that lambda'ing here would not help readability, I thought
that when I wrote it; it would quickly spiral out of control and make
things look horrible.
While I certainly appreciate the before / initialize parallel, I
hadn't thought of it like that before. I don't think about ruby when
writing specs, I think about nesting concepts and readability (and
what I am making, ofc), that's why I use rspec. Well, that and being
told to when I started :)
I write describe/context blocks to describe context, not to define
classes. That's where I'm coming from when saying I want my context
call and its setup to be on one line, rather than the setup being
portrayed as encapsulated by the concept rather than part of it.
Looking at it as a class definition is making this seem a lot less
weird now. I don't know if that's a good thing or not, but thanks.
Before blocks are in common use and people know to look for them so
don't introduce an alternative to confuse things -- yep, very valid
point.
I guess the short answer is no, stop being silly, this works well
within the language limitations, and the suggested alternative will
end up looking the same or worse.
Still, I found it interesting. Thanks for the feedback.
Running under the fence indeed, which hedge do these faults and
failures creep out from ;)
Nick
On Sep 22, 6:38 am, Stephen Eley <sfe...@gmail.com> wrote:
> On Sun, Sep 20, 2009 at 9:34 PM, nruth <nick.rutherf...@gmail.com> wrote:
>
> > We're using a describe (or context) block to name (or document) a
> > state, then using a separate before block to set up that state
> > (context). If that before block were to go astray the documentation
> > would cease to be correct.
>
> On further reading and thinking, I think I might see some of the
> confusion. You're not quite correct that the describe and the before
> are "separate blocks." The before block lives *inside* the describe
> block, and composes part of what is described.
>
> The describe block is more than "documentation." It's a class
> definition. (Literally.) Class definitions do more than just provide
> names; they bundle up behavior. The before block can (not literally,
> but effectively) be considered as a sort of constructor method for the
> class, similar to 'def initialize' in a non-RSpec class but with more
> chaining built in. Nested example groups are subclasses that invoke
> the superclasses's constructors automatically, etc.
>
> This is all very clean, mostly traditional object-oriented language
> behavior. Your suggestion of putting the initializer as a block value
> to a hash option is more complicated; it's like saying normal Ruby
> classes should not have an 'initialize' method, but instead should be
> declared like 'class Foo :constructor => lambda{initializer code
> here}'. Ruby's insistence that you should call 'new' but implement
> 'initialize' is confusing enough. The lambda-option style doesn't
> make it clearer.
>
> Does that make sense? "Describe" and "before" aren't disconnected
> entities. They're body and organ. One is a part of the other.
>
> --
> Have Fun,
> Steve Eley (sfe...@gmail.com)
> ESCAPE POD - The Science Fiction Podcast Magazine
> http://www.escapepod.org
> _______________________________________________
> rspec-users mailing list
> rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
