....ah...yes I see...we need a Wizard (very good, let's do it!). On Tue, Sep 1, 2009 at 1:56 PM, Jason Meckley <[email protected]>wrote:
> > 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 > > > -- 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 -~----------~----~----~----~------~----~------~--~---
