Ayende @ Rahien

Krzysztof Koźmic commented on On API Design

Mon, 28 Apr 2008 06:02:44 GMT

@Gian. That was also my main goal. Not necessarily to expand it's capabilities, but what can be done to simplify access to those features that are already out there. How to make it easier for newcomers to start using it, and how to make it more likely for them to succeed.

Gian Maria Ricci commented on On API Design

Sat, 26 Apr 2008 06:39:46 GMT

I like the idea of the Facade, it is a good way not to break compatibility, but could give access only to the core functionality, to not "distract" new user with all the capability of the library. alk.

Joseph Gutierrez commented on On API Design

Tue, 22 Apr 2008 14:33:02 GMT

Facade would be nice. With the 'in your face API'.

Mike Minutillo commented on On API Design

Tue, 22 Apr 2008 03:39:45 GMT

Out of interest I would look at the opportunity make the API more explicit (i.e. the "In your face" option specified) but add in a set of Compatability Extension Methods. These could be included (or not) at the users discretion to provide "simple" options via overloads. This makes the distinction clear between what is Core functionality and what is syntactic sugar. This way all that is required for backward compatability is to include a new namespace or two. Of course, this only really works for VS2008 customers.

Benny Thomas commented on On API Design

Mon, 21 Apr 2008 22:08:55 GMT

I dont see any problem in breaking the api. But I understand the documentationpart. Who doent hate to write documentation.

Nikola Malovic commented on On API Design

Mon, 21 Apr 2008 20:36:50 GMT

I like the facade idea. Sounds easier to explain to people rhino basics which is very scary for some people starting to use mocks.

Krzysztof Koźmic commented on On API Design

Mon, 21 Apr 2008 20:03:19 GMT

Notice that I suggested not changing current MockRepository (at least for few releases), but creating a Facade for it. This way you don't break anything. I'm not sure I understand what you mean by "In your face design". Having methods that explicitly state kind of mock/stub you create is as explicit as using enum to denote it. I agree, People will use DynamicMock 95% of the time (probably with no constructor parameters or multimocks). With syntax I suggested its simply: var foo = repo.Mock(); I don't see forcing anyone to deal with all options explicitly here. It's even less explicit than var foo = repo.DynamicMock(); Also by using enum with FlagsAttribute you hide options like mocks with remoting that 99% users will never use. And as with everything - each choice has pros and cons. I'm not saying mine is the only one right, I'm far from that. I wanted to start a debate and I'm glad I succeeded with that. PS. I also updated my example, to make it even a bit simpler.