Alex, a simpler API would lower the entry level. But lets also not forget (as much as we want to) the entry level for .net development is "where is the IDE Wizard?" that said moving the old syntax to another namespace still makes the option available and can confuse the developer. If you're trying to reduce the surface area, and reduce friction; move the old functionality to another assembly (Rhino.Mocks.OldSchool.dll). This way the user needs 2 assemblies for backwards compatibility. moving forward (4.1?) Rhino.Mocks.OldSchool.dll is dropped altogether.
On Sep 1, 12:55 pm, Alex McMahon <[email protected]> wrote: > I think a good goal is to reduce the barrier to entry of Rhino Mocks. > I see a lot of questions being asked on the mailing list that are a > result of new users trying to get to grips with the tooling and > wandering down paths that lead to the same common errors, e.g. mixing > different syntaxes together. > > If we can achieve this without losing any functionality or syntaxes > then that seems ok, but the default and easiest exploration path > should be limited to the chosen syntax (AAA). > > Perhaps this means moving all the classes relating to older syntaxes > into a different namespace (Rhino.Mocks.Interop? probably a better > name would be needed) so people can upgrade to 4.0 and keep everything > the same by just adding a using to this namespace. Then in the main > namespace (Rhino.Mocks) we keep as small a surface area so that a new > user could pretty much get started just by using intellisense. > > When a user starts using the Interop namespace and getting it all > mixed up leading to asking the questions (as I'm sure some will) we > can say "The Interop namespace is designed only for backwards > compatibility scenarios, please use the Rhino.Mocks.Fake class and > seehttp://ayende.com/wiki/Rhino+Mocks.ashxfor usage details" > > 2009/9/1 Tim Barcz <[email protected]>: > > > 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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
