by Michael S. Kaplan, published on 2005/07/15 16:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/07/15/439395.aspx
(more experimentations with pre-recorded messages!)
Earlier today I told everyone Don't roll your own GetDateFormat and even showed an example consequence of doing so, when Microsoft Office would fail to pick up the right support for genitive dates, an important functionality in several locales.
Everyone knows that collation is what I like best, so I wanted to write that you should not try to do the same sort of thing with CompareString. But then I realized that whether one is thinking about the C Runtime, the Shell Lightweight API (shlwapi), or the .NET Framework, people like to roll their own functions and wrappers for this stuff, and show no signs of slowing down how many are added from version to version. I have been covering the differences for some time now in a variety of posts....
The arguments to not do such things simply do not pull the same weight as they do in the GetDateFormat case, since any time you claim a feature is missing or broken by their wrapper, it is trivial to claim that the feature is not needed for callers of the new function. If they do need it, then they write a new wrapper!
But this precedent does not require you, the customer, to do the same thing. The wrapper idea is a dangerous one. Not usually for the one who writes the wrapper at the time they write it (since hopefully flags will have been carefully thought out and planned). But if you use the same function later on, or if someone else sees it and decides to use it, then it becomes more and more difficult to determine whether the usage is correct, and what the side effects may be.
Someone over in the world of .NET was explaining to me why the fact that macros were not included in C# was a good thing. Now I do not completely buy the agruments about obfuscation of functionality and such, but if someone does buy the argument, then don't wrapper methods and functions violate the same gudielines of code library transparency?
I am probablyobviously losing this particular battle in many of the libraries that Microsoft ships (and removing methods is a worse problem than the one I am arguing here!), but I still have hope that customers will not fall into this same trap (or at least minimize the amount of falling that they do!). The basic methods are not that hard to use, so why not give them a try? :-)
This post brought to you by "ಔ" (U+0c94, a.k.a. KANNADA KETTER AU)
referenced by