"Don't fix what ain't broke." is an old saying in our parts.
@Joe Chung: Yeah, but then wouldn't have the nice pretty Ribbon with Office 2007.
I vote for changing it. And that's based on nothing more than gut feeling. Offer both versions for a transition period if you must but I wouldn't.
Hi Roy,
I totally agree. If the method name doesn't correctly convey what the method does, then 'It's Broke' and it needs to get fixed. A poorly worded method is as much a bug as a method that doesn't do what the developer intended. As a developer who has been forced to maintain other's code, I fight with poorly worded methods day in and day out.
Developers should keep in mind that your code has two audiences, the compiler and the developer. Both are important and should be treated with the same respect.
Ta.
Steve Porter
I am torn. If there is a convention present among other mocking frameworks then we should likely honor them.
Personally I have always found the name DynamicMock and PartialMock confusing. If most people are like me and remain confused it should be changed after fair warning and a long period as an obsolete method.
Would a better term for PartialMock be NonStrictConcreteMock?
Or why not just wrap those functions within your own conventions within your test cases?
I wouldn't mind that change. I think it would be helpful, and worth coping with any fallout for the improvement in readability.
I don't think there's much point in the change, it's semantics.
When I first started using RhinoMocks I didn't know what the difference was between Dynamic, Partial and just plain mock. But, I honestly don't think I would have known the difference between Strict, Non-Strict and Partial Non-Strict.
I agree with James.
Although the topic of this article is excellent discussion fodder, I'm not sure your example makes the point.
I've never used Rhino.Mocks (but am familiar with mock objects) and wouldn't have guessed correctly the purpose of your proposed API changes. Therefore, in this case, introducing such an API change doesn't provide much value over the current API with which people may already be familiar.
Ultimately, a well-known API is worth more than a correct one. As a result, any changes to such a well-known API must have an exceptionally low risk, and provide exceptional value to be worthwhile.
FWIW, usually whenever I find an API lacking in some way, I just wrap it within my base test classes or other helper classes to simplify my own development and allow my own semantics to clarify the intent.
- I would leave legacy signatures as it is
- I would allow to override default signature behavior via configuration or programmatical context setting
- I would add the refined signature
- I would mark the legacy signatures as obsolete if it make sense
I can create an extension method in C# to change the language of the API... and of course, so could Oren if he wanted to provide new expressions of mock object creation for only those users who wanted them...
When discussing backwards compatibility, it's important to consider the consequences of breaking it.
As an Enterprise Developer™, I'm used to having full access to the entire code base (I know all consumers of every server in the application). Even in large projects, where changing a signature might entail a bit of work, it's definitely doable.
On the other hand, if you are shipping software to anonymous clients (as Oren is), backwards compatibility becomes VERY important. If you just change the API, you are going to break a lot of existing code out there.
While the fix might be simple in this case, Oren would still be running the risk of alienating his 'customers', so I can definitely understand why he's wary of doing so. It would cause existing users extra trouble without adding much value.
Obviously, if you really want to change an API in a similar situation, using the Obsolete attribute is the correct next step, but I don't think the current situation warrants this, as the difference is purely semantic.
The fact that the issue is one of semantics is certainly a valid point but I wonder if it doesn't miss the forest for the trees. Aren't many usability issues rooted in problems with unclear, inconsistent or inappropriate semantics? I'm new to Rhino.Mocks and I really like the framework but unlike a few of the other folks who've commented 'Strict', 'NonStrict', etc. would have been really useful cues during the learning process about what the various mock creation methods actually do.
I too am new to Rhino.Mocks and I agree with e. muniz.
I vote for clarity, and that means changing the names.