by Michael S. Kaplan, published on 2011/10/28 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/10/28/10231034.aspx
Previous posts in the series are Improving genitive. Or not.... (part 1) and Improving genitive. Or not.... (part 2): Explaining the point of Part 1. and Improving genitive. Or not.... (part 3): The hazards of "off label" usage.
Now in response to that third part, Van commented:
So I guess the question is why we can't just leave the genitive month algorithm as is, but incorporate two new month name variables - an invariant nominative and genitive - that will implement regardless of or contrary to the genitive month algorithm. I mean, if your old assumptions don't work anymore, keep the old stuff around for when it's needed and implement a new way that will work, no?
Okay, so in that one question there are actually several ideas:
Obviously point #1 is what we have been doing to date. Unfortunately.
Point #2, if the eventual fix was to be done by Microsoft, has no specific purpose since all that data is already available. Now unless the goal was to give customers or ISVs an easier way to do their own parsing and formatting, which also as little point since that is possible now by formatting just "MMMM" vs. "d MMMM".
The central ideaof trying to fix the bug would be to extend the current support, in ways that do not break expectations.
It seems unlikely that they will do that, given the wide variety of uses that are happening (which is a lot of what this series is about). Changes would have to exist for both parsing and formatting, and perhaps the only hope of that happening is some future version where there ere compelling scenarios to fix.
Up until now, he judge has consistently dismissed the case due to lack of substantive evidence of a problem that needs fixing.
Put simply, there has to be a "smoking gun" to make that happen.
At some point, I'll talk more about what probably would be required here, were such a campaign be launched. At this point, I'm not launching one, or even advocating it happen. But it can be a useful exercise to walk through what would be needed to get resources allocated....
John Cowan on 28 Oct 2011 8:58 AM:
This is the general problem with bug fixing: there are always people who have come to depend on the bug, and complain bitterly when you fix it, because their code now breaks, and what about all your promises of backward compatibility?
"But it's wrong!"
"We don't freaking CARE."
Unfortunately, there simply is no general solution.
Michael S. Kaplan on 28 Oct 2011 12:43 PM:
Thinking outside the box, given the limitations on how the detection works, it is not impossible to improve the situation a little bit. The team that owns it would have to be willing to do the work, but it isn't impossible to make any improvements....
referenced by