by Michael S. Kaplan, published on 2010/08/03 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/08/03/10028245.aspx
So the question in email was [for me, at least] wholly depressing:
Hi,
What I would like to understand more is why Silverlight CLR Covert.ToDouble(string) would
1. Default to convert the string using the current culture of machine and not IE
2. Instead of using Invariant Culture use Current Culture.
In my scenario we wrote double to string conversion in Silverlight client and that started failing on the client machine where regional setting are set to “Norvey” and IE set to “English US”.
Many Thanks
Why did I find this to be so depressing?
Where do I start?
Well there is the fact that it kinda makes sense as a default since strings will often come from users and expecting users to not follow their own stated preferences would be a little bit crazy.
And there is the fact that every version of .Net that has ever shipped Convert.ToDouble(string) overload has used the CurrentCulture by default - so a change in expectations would be a nightmare of behavior documentation with a myraid of clones doing stuff differently in ways no sane user will be able to fully grasp.
And of course there is the fact that since the user has to support both scenarios, ar least one of which uses or should use the current default, that the developer can just suck it up and write the code correctly, even if they feel the wrong choice was made for the default.
Many object about how different "The Silverlight Scenario" is and how it might make sense to do things differently, but I call NO WAYon that one -- if you want behavior to be different because everything being done is different then you DO NOT GIVE EVERYTHING THE EXACT SAME NAME TO EASE DEVELOPMENT since different behavior will negate that rapid dev pretty fast.
Now if people want to have the philosophical argument about should they have chosen the default differently then that's okay. But probably that is better for a fireside chat since the conversations will not be able to impact existing stuff anyway, so not everyone will be interested.
All I can say is that I am glad that it isn't just me arguing against willy-nilly architectural changes spec'ed out on the back of a cocktail napkin favoring new scenarios and willing to change behavior out from under the old ones.
Because lots of people pointed out those same issues.
So there are people looking after the design here. :-)