Oh, no. The guts are still the same. There are things there that need to handle some very freaky situations.And they work, so no reason to touch them.
We are talking about a plastic surgery rather than open heart surgery On Tue, Sep 1, 2009 at 8:18 PM, Tim Barcz <[email protected]> wrote: > If you're getting rid of record/replay will you still use the underlying > "guts" or will this be a ground up rewrite? > > > On Tue, Sep 1, 2009 at 11:57 AM, Ayende Rahien <[email protected]> wrote: > >> I think we can pretty much kill it. If they need backward compact, they >> can use 3.6 >> >> On Tue, Sep 1, 2009 at 7:19 PM, Tim Barcz <[email protected]> wrote: >> >>> Do we need to kill backwards compatibility. I'm working on a patch/spike >>> where the class Fake is used which really just calls MockRepository under >>> the hood? >>> >>> Thoughts? >>> >>> >>> On Tue, Sep 1, 2009 at 10:56 AM, Ayende Rahien <[email protected]>wrote: >>> >>>> This is a blog post that would show up day after tomorrow, I am posting >>>> it here to get some traction in the mailing list before we make it really >>>> public. >>>> >>>> Well, now that Rhino Mocks 3.6 is out of the way, we need to think about >>>> what the next version will look like. >>>> >>>> Initially, I thought to match Rhino Mocks 4.0 to the .NET 4.0 release >>>> and support mocking dynamic variables, but while this is still on the >>>> planning board, I think that it is much more important to stop and take a >>>> look at where Rhino Mocks is now and where we would like it to be. >>>> >>>> I started Rhino Mocks about 5 years ago, and the codebase has stood well >>>> in the test of time. There aren’t any nasty places and we can keep >>>> releasing >>>> new features with no major issues. >>>> >>>> However, 5 years ago the community perception of mocking was different >>>> than what it is now. Rhino Mocks hasn’t really changed significantly since >>>> it 1.1 days, for that matter, you can take a code base using Rhino Mocks >>>> for >>>> .Net 1.1 and move it to Rhino Mocks 3.6 with no issues. >>>> >>>> But one of the most frequent complaints that I have heard is that Rhino >>>> Mocks API has became too complex over the years, there are too many options >>>> and knobs that you can turn. I know that my own style of interaction >>>> testing >>>> has changed as well. >>>> >>>> The current plan for Rhino Mocks 4.0 is that we will break backward >>>> compatibility in a big way. That means that we are going to drastically >>>> simplify everything in the framework. >>>> >>>> We are still discussing this in the mailing list, but currently it looks >>>> like we will go with the following route: >>>> >>>> - Kill the dynamic, strict, partial and stub terminology. No one >>>> cares. It is a fake. >>>> - Remove the record / playback API. The AAA method is much simpler. >>>> - Simplify mocking options, aiming at moving as much as possible >>>> from expectation style to assert style. >>>> - Keep as much of the current capabilities as we can. That means >>>> that if Rhino Mocks was able to support a scenario, it should still >>>> support >>>> it for the 4.0 version, hopefully in a simpler fashion. >>>> >>>> The end result is putting Rhino Mocks on an API diet. I am looking for >>>> help in doing this, both in terms of suggested syntax and in terms of >>>> actual >>>> patches. >>>> >>>> You are welcome to contribute… >>>> >>>> >>>> >>> >>> >>> -- >>> Tim Barcz >>> Microsoft ASPInsider >>> http://timbarcz.devlicio.us >>> http://www.twitter.com/timbarcz >>> >>> >>> >>> >> >> >> > > > -- > Tim Barcz > Microsoft ASPInsider > http://timbarcz.devlicio.us > http://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 -~----------~----~----~----~------~----~------~--~---
