No hesitation...
On Jun 14, 2:20 pm, Tim Barcz <[email protected]> wrote:
> And there it comes!
>
> :-)
>
>
>
>
>
> On Sun, Jun 14, 2009 at 2:09 PM, Tim Barcz <[email protected]> wrote:
> > I think it sounds like a cool addition. Admittedly I don't use an
> > auto-mocking container and so I can't comment much further than that. That
> > said, I think Rhino in general needs to talk about freezing support for
> > Record/Replay and work more towards AAA syntax.
>
> > This brings the issue to light because of breaking changes....which may be
> > a viable trade off if it moves the product in the direction we want.
>
> > Tim
>
> > On Sun, Jun 14, 2009 at 2:04 PM, Adam Tybor <[email protected]> wrote:
>
> >> I just built a patch for using the AMC with the new AAA 3.5 syntax. I
> >> would like to commit it but I wanted to see if anyone had any
> >> objections to a minor breaking change?
>
> >> Currently on the AMC there is a property that exposes the instance of
> >> the MockRepository, in order to implement my patch I changed the
> >> dependency on MockRepository to a new type IMockRepository in the AMC
> >> assembly. I then built two adapters, 1 just delegates all calls back
> >> to an instance of a MockRepository, everything works the exact same.
> >> The second adapter intercepts calls and uses the new static methods
> >> for AAA on the MockRepository itself. Since AAA has a lot less
> >> functionality compared to using record/playback many calls just throw
> >> NotAvaliableInAAAMode exceptions.
>
> >> The breaking change is if people are doing anything with
> >> MockRepository off of the AMC itself. If so the impact is minimal as
> >> the interface has the exact same methods and signatures as the actual
> >> MockRepository, however if you are storing references to the
> >> MockRepository property and are not using "var" you will have to
> >> update a variable declaration:
>
> >> Example of breaking changes:
> >> MockRepository myMocks = amc.MockRepository
>
> >> IMockRepository myMocks = amc.MockRepository.
>
> >> Any thoughts?
>
> >> The only other idea I had was to mark all methods on the
> >> MockRepository itself as virtual so I could just use inheritance, but
> >> I would prefer to put the adapters in place so RhinoMocks doesn't have
> >> to be patched as well.
>
> >> Adam
>
> > --
> > Tim Barcz
> > ASPInsider
> >http://timbarcz.devlicio.us
> >http://www.twitter.com/timbarcz
>
> --
> Tim Barcz
> 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
-~----------~----~----~----~------~----~------~--~---
