On Aug 06, 2010, at 11:58 am, David Chelimsky wrote:
> Barring the unforeseen, I'll knock out beta.20 this weekend.
Cool, ta!
Cheers
Ash
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users
On Aug 6, 2010, at 3:18 AM, Ashley Moran wrote:
>
> On Aug 05, 2010, at 4:28 am, David Chelimsky wrote:
>
>> At this point, the customization block is still being eval'd after the
>> shared block, and I'm fairly well convinced this is the right thing, in
>> combination with params to the block
On Aug 05, 2010, at 4:28 am, David Chelimsky wrote:
> At this point, the customization block is still being eval'd after the shared
> block, and I'm fairly well convinced this is the right thing, in combination
> with params to the block.
I don't think it makes any different any more, at least
On Aug 04, 2010, at 12:41 pm, David Chelimsky wrote:
> What happens if the shared spec author really wants it to just be a hash? Do
> you think that's a valid use case?
It could get in the way, then, I guess. You'd always have the original hash
parameter if you wanted to use the method, but I
On Aug 4, 2010, at 1:35 PM, Myron Marston wrote:
>> I wouldn't even bother to undef those methods.
>
> If we don't undef the methods, then the semantics of the
> #module_eval_with_args (or whatever we call it) will be different on
> 1.8.6 and other versions. On 1.8.6, a method definition in the
> I wouldn't even bother to undef those methods.
If we don't undef the methods, then the semantics of the
#module_eval_with_args (or whatever we call it) will be different on
1.8.6 and other versions. On 1.8.6, a method definition in the block
would define both an instance method _and_ a class me
On Aug 4, 2010, at 1:55 AM, Myron Marston wrote:
> Ashley: thanks for posting the example. It's nice to see how this all
> fits together.
>
> Re: RSpec 2 for ruby 1.8.6: I don't see RSpec 2 as being all that
> useful for Rails 2.x projects on ruby 1.8.6. However, it's still very
> important fo
On Aug 4, 2010, at 3:43 AM, Ashley Moran wrote:
>
> On 4 Aug 2010, at 1:05 AM, David Chelimsky wrote:
>
>>
>
>
> One other thought I've had is keyword syntax. While currently I'm writing:
>
> it_satisfies_contract "[Entity] Collection:", :children, :child, Child.name
>
> I prefer keyword
On 4 Aug 2010, at 1:05 AM, David Chelimsky wrote:
>
One other thought I've had is keyword syntax. While currently I'm writing:
it_satisfies_contract "[Entity] Collection:", :children, :child, Child.name
I prefer keyword arguments, so I'd like to write:
it_satisfies_contract "[Entity] C
On 4 Aug 2010, at 7:55 AM, Myron Marston wrote:
> Ashley: thanks for posting the example. It's nice to see how this all
> fits together.
Arguably it would have made more sense to post that example *before*, rather
than expecting you all to read my mind :)
I'm pleased with how it's working out
On 4 Aug 2010, at 1:05 AM, David Chelimsky wrote:
> I actually like contract a lot. Maybe we'll need alias_shared_examples_for_to
> :)
Haha, actually that gets +1 from me! Should I file a ticket? :)
In general I like contract, I just wasn't sure it was the right word for this
usage of shared
Ashley: thanks for posting the example. It's nice to see how this all
fits together.
Re: RSpec 2 for ruby 1.8.6: I don't see RSpec 2 as being all that
useful for Rails 2.x projects on ruby 1.8.6. However, it's still very
important for gems. I just converted one of my projects (VCR[1]) to
RSpec
On Aug 3, 2010, at 4:35 PM, Ashley Moran wrote:
>
> On 3 Aug 2010, at 12:50 PM, David Chelimsky wrote:
>
>> Pushed:
>>
>> http://github.com/rspec/rspec-core/commit/84303616be1ac2f8126675488947b47f6945cebe
>> http://github.com/rspec/rspec-core/commit/3cea7b8bea51766d632e20bcc9ef15c64b719ea1
>
On 3 Aug 2010, at 12:50 PM, David Chelimsky wrote:
> Pushed:
>
> http://github.com/rspec/rspec-core/commit/84303616be1ac2f8126675488947b47f6945cebe
> http://github.com/rspec/rspec-core/commit/3cea7b8bea51766d632e20bcc9ef15c64b719ea1
Awesomeness!
> Please do let me know if this works with what
On Aug 3, 2010, at 6:43 AM, Ashley Moran wrote:
>
> On Aug 03, 2010, at 12:22 pm, David Chelimsky wrote:
>
>> My inclination is to get this feature out with explicit non-support for
>> 1.8.6, and then add support for 1.8.6 if we can get this to work. Working on
>> that now - should be pushing
On Aug 03, 2010, at 12:22 pm, David Chelimsky wrote:
> My inclination is to get this feature out with explicit non-support for
> 1.8.6, and then add support for 1.8.6 if we can get this to work. Working on
> that now - should be pushing some code (including Myron's contribution) later
> today.
On Aug 2, 2010, at 7:52 AM, David Chelimsky wrote:
> On Aug 1, 2010, at 10:08 PM, Myron Marston wrote:
>
>> OK, I tried to implement #module_exec on ruby 1.8.6, and here's what I
>> came up with:
>>
>> http://github.com/myronmarston/rspec-core/commit/364f20ebd5b7d9612227cb6e86a6e8c8c2e9931e
>>
On 1 Aug 2010, at 11:52 PM, David Chelimsky wrote:
> re: order of evaluation of blocks, I think I'm inclined to go one way one
> minute, and another the next. Somebody convince me of one or the other.
One thing that may help clear this up is: can anyone offer a concrete example
of where overri
On 2 Aug 2010, at 4:08 AM, Myron Marston wrote:
> Backports (a library that implements features of later versions of
> ruby in 1.8.6) implements it in a similar fashion:
>
> http://github.com/marcandre/backports/blob/v1.18.1/lib/backports/1.8.7/module.rb
Conceivably, RSpec 2 could depend on Bac
On 2 Aug 2010, at 2:04 AM, Myron Marston wrote:
> I actually find the use of this to be a bit confusing:
>
> [:foo, :bar].each do |arg|
> it_should_behave_like "Something", arg do |a|
># The value of the param is already bound to arg and now it's
> bound to a, too.
> end
> end
>
> I suppo
On Aug 1, 2010, at 10:08 PM, Myron Marston wrote:
> OK, I tried to implement #module_exec on ruby 1.8.6, and here's what I
> came up with:
>
> http://github.com/myronmarston/rspec-core/commit/364f20ebd5b7d9612227cb6e86a6e8c8c2e9931e
>
> It works (at least in the sense that it allows the specs an
OK, I tried to implement #module_exec on ruby 1.8.6, and here's what I
came up with:
http://github.com/myronmarston/rspec-core/commit/364f20ebd5b7d9612227cb6e86a6e8c8c2e9931e
It works (at least in the sense that it allows the specs and features
I added in the previous commits in that branch to pa
> If we do this, we should use module_exec for both blocks so they both get the
> same arguments.
I actually find the use of this to be a bit confusing:
[:foo, :bar].each do |arg|
it_should_behave_like "Something", arg do |a|
# The value of the param is already bound to arg and now it's
bo
On Aug 1, 2010, at 5:12 PM, Ashley Moran wrote:
>
> On 1 Aug 2010, at 3:43 PM, David Chelimsky wrote:
>
>> shared_examples_for "blah" do |a,b|
>> ...
>> end
>>
>> it_should_behave_like "blah", 1, 2
>>
>> That wouldn't have worked with the old implementation, but it would work
>> perfectly we
On Aug 1, 2010, at 5:39 PM, Myron Marston wrote:
>> Seems like your mental model is that of a customization block being a
>> subclass or re-opening of the shared block. What you say makes sense in that
>> model, but that's not the same model I have.
>
> My mental model is indeed that the custom
> Seems like your mental model is that of a customization block being a
> subclass or re-opening of the shared block. What you say makes sense in that
> model, but that's not the same model I have.
My mental model is indeed that the customization block is like a
subclass. I'm not sure where I g
On 1 Aug 2010, at 3:43 PM, David Chelimsky wrote:
> shared_examples_for "blah" do |a,b|
> ...
> end
>
> it_should_behave_like "blah", 1, 2
>
> That wouldn't have worked with the old implementation, but it would work
> perfectly well now. This would also "just work" with hash-as-keyword-args:
On Aug 1, 2010, at 11:40 AM, Myron Marston wrote:
>> The particular issue of simple values being used in the docstrings and the
>> examples themselves (i.e. exposed to everything in the block scope) could be
>> handled like this:
>>
>> shared_examples_for "blah" do |a,b|
>> ...
>> end
>>
>>
> The particular issue of simple values being used in the docstrings and the
> examples themselves (i.e. exposed to everything in the block scope) could be
> handled like this:
>
> shared_examples_for "blah" do |a,b|
> ...
> end
>
> it_should_behave_like "blah", 1, 2
Fantastic idea. I'm sold.
On Jul 31, 2010, at 1:06 PM, Myron Marston wrote:
>> You can still get the same outcome, but you have to implement it in the
>> group like this:
>
>> unless defined?(:foo)
>> def foo; "foo"; end
>> end
>
> Good point--I hadn't thought of that. The one issue I see with it is
> that the author
On Aug 1, 2010, at 9:43 AM, David Chelimsky wrote:
>
> On Jul 31, 2010, at 1:06 PM, Myron Marston wrote:
>
>>> You can still get the same outcome, but you have to implement it in the
>>> group like this:
>>
>>> unless defined?(:foo)
>>> def foo; "foo"; end
>>> end
>>
>> Good point--I hadn't t
On Jul 31, 2010, at 7:06 pm, Myron Marston wrote:
> I think this is a clunky way to essentially pass a parameter to the
> shared example group. Better would be something like this:
>
> it_should_behave_like "something" do
> providing :method_name, :foo
> end
After sleeping on this, I found an
On 31 Jul 2010, at 7:06 PM, Myron Marston wrote:
> Good point--I hadn't thought of that. The one issue I see with it is
> that the author of the shared example group may not have knowledge of
> which helper methods consumers will need to override. So he/she
> either defines all helper methods t
> You can still get the same outcome, but you have to implement it in the group
> like this:
> unless defined?(:foo)
> def foo; "foo"; end
> end
Good point--I hadn't thought of that. The one issue I see with it is
that the author of the shared example group may not have knowledge of
which help
On 31 Jul 2010, at 1:10 AM, David Chelimsky wrote:
> You can still get the same outcome, but you have to implement it in the group
> like this:
>
> unless defined?(:foo)
> def foo; "foo"; end
> end
Maybe a DSL method while I'm working on it? Maybe:
default_helper(:foo) do
"foo"
end
On Jul 30, 2010, at 6:56 PM, Myron Marston wrote:
> On Jul 30, 2:58 pm, Ashley Moran
> wrote:
>> On 30 Jul 2010, at 5:00 PM, David Chelimsky wrote:
>>
>>> By all means.
>>
>> I've started on that and filed a ticket[1].
>>
>> One question I have, is I keep calling the Example Group that uses a
I may be the only one who finds this useful, but I think there's value
in evaluating the customization block after the shared example group
block. It allows the shared example group to provide a default
implementation of a helper method, and then an instance of the shared
behavior to override the
On 30 Jul 2010, at 5:00 PM, David Chelimsky wrote:
> By all means.
I've started on that and filed a ticket[1].
One question I have, is I keep calling the Example Group that uses a shared
block the "host group". Is there already a name for it? I never know what to
use, and I'm not sure "host
On Jul 30, 2010, at 4:47 pm, David Chelimsky wrote:
> If I provide spec extensions for a library (other than RSpec in this case)
> that include a shared group that "you can use to spec your foos to make sure
> they comply with this API" (or whatever), then this sort of thing can be very
> help
On Jul 30, 2010, at 10:17 AM, Wincent Colaiuta wrote:
> El 30/07/2010, a las 16:10, David Chelimsky escribió:
>
>> Actually - maybe I spoke to soon. Ordering things this way would mean that
>> you couldn't do this:
>>
>> shared_examples_for Enumerable do
>> def enumerable
>> raise "you must
On Jul 30, 2010, at 10:57 AM, Ashley Moran wrote:
>
> On Jul 30, 2010, at 3:10 pm, David Chelimsky wrote:
>
>> Maybe that, or a DSL that wraps that, is the better way, so we can get the
>> best of both worlds?
>>
>> shared_examples_for Enumerable do
>> require_instance_method :foo, "gotta hav
On Jul 30, 2010, at 3:10 pm, David Chelimsky wrote:
> Maybe that, or a DSL that wraps that, is the better way, so we can get the
> best of both worlds?
>
> shared_examples_for Enumerable do
> require_instance_method :foo, "gotta have foo instance method"
> require_class_method :foo, "gotta ha
El 30/07/2010, a las 16:10, David Chelimsky escribió:
> Actually - maybe I spoke to soon. Ordering things this way would mean that
> you couldn't do this:
>
> shared_examples_for Enumerable do
> def enumerable
>raise "you must provide an enumerable method that returns the object which
> yo
On Jul 30, 2010, at 9:03 AM, David Chelimsky wrote:
>
> On Jul 30, 2010, at 5:13 AM, Ashley Moran wrote:
>
>> Hi
>>
>> I finally looked into why this is not currently possibly in RSpec 2 (beta
>> 19):
>>
>> shared_examples_for "Etymology" do
>> describe "The etymology of foo" do
>> it
On Jul 30, 2010, at 5:13 AM, Ashley Moran wrote:
> Hi
>
> I finally looked into why this is not currently possibly in RSpec 2 (beta 19):
>
> shared_examples_for "Etymology" do
>describe "The etymology of foo" do
> it "is followed by #{after_foo}" do
># ...
> end
>end
45 matches
Mail list logo
