"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.