I'm really glad to hear the news and I'm looking forward to the new
RhinoMocks release! I was one of the people complaining about
complexity, I had to teach my team in RM 3.0 and 3.5. I'm glad that
simplicity is rated more important than backward compatibility, even
if it hurts. Otherwise developers will choose something simpler than
Rhino for new projects and Rhino will die in the long run - which I
would avoid at all costs.
A suggestion: A backward-compatibility-API could be put into a certain
namespace ("legacy") which is normally not used. It could be
implemented as a wrapper to the new API (certainly not complete, but
to some degree), or by compiling 3.6 and 4.0 into the same assembly,
moving 3.6 into this new namespace. This will be good enough for
existing projects and not burden the development of new concepts and
innovations.
Thanks a lot for this great tool!
On 1 Sep., 23:18, Ayende Rahien <[email protected]> wrote:
> I wasn't, do listen to that, it is somewhere in the first 15 minutes.
>
> On Tue, Sep 1, 2009 at 10:35 PM, Tim Barcz <[email protected]> wrote:
> > I was being facetious ...
>
> > On Tue, Sep 1, 2009 at 2:29 PM, Ayende Rahien <[email protected]> wrote:
>
> >> Hm, listen to my DNR from Oredev about Rhino Mocks.Specifically, to Carl
> >> asking what Rhino Mocks is.
>
> >> On Tue, Sep 1, 2009 at 10:09 PM, Tim Barcz <[email protected]> wrote:
>
> >>> ....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.ashxforusage 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
>
> > --
> > 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
-~----------~----~----~----~------~----~------~--~---
