“Why does StrignBuilder.AppendFormat() need anything more than AppendFormat(string, object)?” — Curious StringBuilder.AppendForamt user
This is a great question. Before I begin, let’s visit what overloads AppendFormat has….AppendFormat( string, object);
AppendFormat( string, object, object);
AppendFormat( string, object, object, object);
AppendFormat( string, object);
AppendFormat (IFormatProvider, string, object)
An obvious question is, why do we need the first three (the ones in blue)? (Obviously, we need the one with IFormatProvider…)
Here is what I learnt:
1) Some languages doesn’t support “params” syntax. By having those overloads, we allow a short cut that allow the developer to directly use it without having to create an array.
2) Allows the option for the CLR engine to do performance optimization (without array creation or other optomization) on common scenarios. (However, the CLR engine has not taken up on this option…)
In the past 5 months on the BCL team, I have learnt alot about design decisions made on the current BCL APIs and some of its consequences. Many times, the lessons of poor design does not show up until you have ship multiple version of the APIs. I think I am gonna start sharing some of the stuff I picked up from the team on this blog. Since V1, the BCL team has lots of experiences to share. A lot of successes, and some failures ;). (By the way, if you don’t know already, Krzysztof and Brad did a great job of sharing some of the successes and failures in his Framework Design Guidelines book. It’s a great read! The BCL team is the Guidelines’ first customer, and I find VERY intersting to learn how the BCL APIs relates or drive these guidelines.) Anyways, my first post on this topic is not really a “lessons learnt”, it is more a “I always wonder why….”.
If you have any “I always wonder why the BCL did <Some API> this way…”, please send it to me. I’d love to find out and share with you.