Yeah, the only change to the public interface would be from Return(T value) to Return(params T[] values) The great thing about this is that this change will not break old code. I'm sure the internal changes would be quite substantial though, but worth it!!! I regularly come across situations where this kind of thing is needed. Especially when I have some sort of Factory pattern for instance creation.
Mark Whitfeld Habanero Development Team http://www.habanerolabs.com On Dec 11, 5:24 pm, Tim Barcz <[email protected]> wrote: > When I initially looked at it I thought it make some sense, however the > implementation is a bit interesting because now rather than using "Return" > the correct type you're you have to pass in a params array of the correct > type. I believe it's doable, but it also increases the surface area of the > code base. > > Tim > > On Fri, Dec 11, 2009 at 6:03 AM, Mark Whitfeld <[email protected]>wrote: > > > > > Hi Tim > > > I was wondering what your verdict was with the correct behaviour for > > ordered returns, etc. > > Have you had a look at my suggestion above? > > I think that it would solve all ambiguity. > > > Mark Whitfeld > > Habanero Development Team > >http://www.habanerolabs.com > > > On Nov 23, 9:10 am, Mark Whitfeld <[email protected]> wrote: > > > I would definitely agree that last in should win, but also that it > > > would be nice to have something like what Tim suggested above. > > > I thought of another syntax for this possibility. How about: > > > > mock.Stub(x=>x.Foo()).Return(1,2); > > > > This would just use a parameter array to specify the desired returns > > > in order and therefore you would get the 'last in' winning and the > > > desired ordered returns. > > > What do you think? > > > > Mark Whitfeld > > > Habanero Development Teamhttp://www.habanerolabs.com > > > > On Nov 22, 4:09 pm, Tim Barcz <[email protected]> wrote: > > > > > There are cases where a call may be made twice and and each time you > > want > > > > something different called. > > > > > mock.Stub(x=>x.Foo()).Return(1); > > > > mock.Stub(x=>x.Foo()).Return(2); > > > > > Where the first call returns 1 and the second call returns 2. > > > > > If I can pull it off I was thinking of having the framework approach as > > > > "last in wins" unless the expectation is explicitly set with a number > > of > > > > times. So in the example above, if you called Foo(), 2 would be > > returned > > > > (last in winning). > > > > > However if you had: > > > > > mock.Stub(x=>x.Foo()).Return(1).Repeat.Once > > > > mock.Stub(x=>x.Foo()).Return(2); > > > > > And then called Foo(), you would get 1 (since it was explicitly set > > up). > > > > > Again I don't know if this adds to the confusion or clears it up. > > > > > On Sun, Nov 22, 2009 at 7:38 AM, bill richards < > > [email protected] > > > > > > wrote: > > > > > > looking at the example I think you might think that > > > > > > it will create a queue of stubbed responses. > > > > > > Now that's just crazy talk! I write a fair number of C# classes, most > > > > > of which contain at least one property getter and setter, for > > example: > > > > > > public SomeClass { public string Text { get; set; } } > > > > > > during the course of the application running, I might instantiate > > > > > SomeClass thus: > > > > > > var sc = new SomeClass { Text = "First" }; > > > > > > and then later on I might change the text thus: > > > > > > sc.Text = "Second"; > > > > > > From what you have said above Alex, we should conclude that when > > > > > running the following code: > > > > > > for(var i = 0; i < 2; i++) > > > > > { > > > > > if(i == 0 && sc.Text == "First") > > > > > Console.WriteLine("First value retrieved"); > > > > > > if(i == 1 && sc.Text == "Second") > > > > > Console.WriteLine("Second value retrieved"); > > > > > } > > > > > > I would expect the following output in my Command Window > > > > > > First value retrieved > > > > > Second value retrieved > > > > > > but we all know that that is just nonsense .... so why would anyone > > > > > expect different behaviour from a mocking framework? > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > Groups > > > > > "Rhino.Mocks" group. > > > > > To post to this group, send email to [email protected]. > > > > > To unsubscribe from this group, send email to > > > > > [email protected]<rhinomocks%[email protected]> > > <rhinomocks%[email protected]<rhinomocks%[email protected]> > > > > > > . > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/rhinomocks?hl=. > > > > > -- > > > > Tim Barcz > > > > Microsoft C# MVP > > > > Microsoft ASPInsiderhttp://timbarcz.devlicio.ushttp:// > >www.twitter.com/timbarcz > > > -- > > > You received this message because you are subscribed to the Google Groups > > "Rhino.Mocks" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<rhinomocks%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/rhinomocks?hl=en. > > -- > Tim Barcz > Microsoft C# MVP > Microsoft ASPInsiderhttp://timbarcz.devlicio.ushttp://www.twitter.com/timbarcz -- You received this message because you are subscribed to the Google Groups "Rhino.Mocks" 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/rhinomocks?hl=en.
